4 ms·

Some I found: - I believe it does offer trusted header auth, although I haven’t used it for any of my apps to test out. https://goauthentik.io/docs/providers/p

Some I found: - I believe it does offer trusted header auth, although I haven’t used it for any of my apps to test out. https://goauthentik.io/docs/providers/proxy/custom_headers https://goauthentik.io/docs/providers/proxy/custom_headers - It doesn’t offer “Passwordless email login”, but offers “passwordless login” in the form of passkeys (with a tiny bit of setup). - Definitely offers upstream OIDC, I have my instance set up to be able to sign in through AAD or locally. https://goauthentik.io/integrations/sources https://goauthentik.io/integrations/sources

apitman 3y ago
> I believe it does offer trusted header auth, although I haven’t used it for any of my apps to test out Fixed, thanks. Do you know if custom headers are returned when using forward auth, or only when Authentik is acting as a proxy? > It doesn’t offer “Passwordless email login”, but offers “passwordless login” in the form of passkeys (with a tiny bit of setup). In the case of obligator, email support specifically is important. Passkeys are really cool, but unless I'm mistaken there's no way for me to say "give the owner of this passkey access to this data" even if they've never yet logged in to your system. This is a critical use case which works great with email, even having a built-in way to notify them of their new access. I would love to see passkeys extended with some sort of proof that the passkey is tied to a specific email address (or other global ID), so you can login without talking to an IdP but also get the benefits mentioned above. > Definitely offers upstream OIDC, I have my instance set up to be able to sign in through AAD or locally Already had that one. Were you maybe looking at Authelia? Though I believe I read somewhere that they are working on support too.
- dugite-code 3y ago
  I'm fairly sure you can set custom headers with the forward auth (although I have never used it), you just have to configure it in the reverse proxy as well. I believe you could setup email login by using the email TOTP 2FA much like I use my yubikey for passwordless authentication. You can modify the flows quite extensively... if you know what you are doing
- mynameisvlad 3y ago
  > Already had that one. Were you maybe looking at Authelia? Though I believe I read somewhere that they are working on support too. Very well might’ve been, the mobile view of the table isn’t fantastic so it was quite a bit of scrolling; definitely could have messed that up. > In the case of obligator, email support specifically is important. Passkeys are really cool, but unless I'm mistaken there's no way for me to say "give the owner of this passkey access to this data" even if they've never yet logged in to your system. No, the user would need to enroll it. They could use a social login (upstream OIDC) without logging in through customizations, you can pre-create their user or create it on demand and give it appropriate access based on the upstream response. I don’t think you could implement magic links, even as customizable as it is.
- Borealid 3y ago
  > I would love to see passkeys extended with some sort of proof that the passkey is tied to a specific email address (or other global ID), so you can login without talking to an IdP but also get the benefits mentioned above. "Passkeys" (FIDO2 Authenticators) support this. The CTAP2.1 protocol contains "enterprise attestation", which allows an Authenticator to identify itself uniquely to a particular Relying Party. An explicit design goal of the FIDO standards is to prevent the server from knowing that two different FIDO credentials originated from the same Authenticator (in other words, treaing a new user as non-anonymous). In order to preserve that property, Authenticators need to be explicitly coded with the RPs for which they'll support Enterprise Attestation. If you have such an authenticator, the server can say "give the owner of a passkey presenting a valid Enterprise Attestation for bob@example.com access to this account". But, again, FIDO isn't supposed to let random web sites on the Internet notice that two "different" users are actually using the same passkey (tracking users between web sites!), so you can't get the property you're looking for without Enterprise Attestation.

apitman 3y ago

> I believe it does offer trusted header auth, although I haven’t used it for any of my apps to test out Fixed, thanks. Do you know if custom headers are returned when using forward auth, or only when Authentik is acting as a proxy? > It doesn’t offer “Passwordless email login”, but offers “passwordless login” in the form of passkeys (with a tiny bit of setup). In the case of obligator, email support specifically is important. Passkeys are really cool, but unless I'm mistaken there's no way for me to say "give the owner of this passkey access to this data" even if they've never yet logged in to your system. This is a critical use case which works great with email, even having a built-in way to notify them of their new access. I would love to see passkeys extended with some sort of proof that the passkey is tied to a specific email address (or other global ID), so you can login without talking to an IdP but also get the benefits mentioned above. > Definitely offers upstream OIDC, I have my instance set up to be able to sign in through AAD or locally Already had that one. Were you maybe looking at Authelia? Though I believe I read somewhere that they are working on support too.

dugite-code 3y ago
I'm fairly sure you can set custom headers with the forward auth (although I have never used it), you just have to configure it in the reverse proxy as well. I believe you could setup email login by using the email TOTP 2FA much like I use my yubikey for passwordless authentication. You can modify the flows quite extensively... if you know what you are doing
mynameisvlad 3y ago
> Already had that one. Were you maybe looking at Authelia? Though I believe I read somewhere that they are working on support too. Very well might’ve been, the mobile view of the table isn’t fantastic so it was quite a bit of scrolling; definitely could have messed that up. > In the case of obligator, email support specifically is important. Passkeys are really cool, but unless I'm mistaken there's no way for me to say "give the owner of this passkey access to this data" even if they've never yet logged in to your system. No, the user would need to enroll it. They could use a social login (upstream OIDC) without logging in through customizations, you can pre-create their user or create it on demand and give it appropriate access based on the upstream response. I don’t think you could implement magic links, even as customizable as it is.
Borealid 3y ago
> I would love to see passkeys extended with some sort of proof that the passkey is tied to a specific email address (or other global ID), so you can login without talking to an IdP but also get the benefits mentioned above. "Passkeys" (FIDO2 Authenticators) support this. The CTAP2.1 protocol contains "enterprise attestation", which allows an Authenticator to identify itself uniquely to a particular Relying Party. An explicit design goal of the FIDO standards is to prevent the server from knowing that two different FIDO credentials originated from the same Authenticator (in other words, treaing a new user as non-anonymous). In order to preserve that property, Authenticators need to be explicitly coded with the RPs for which they'll support Enterprise Attestation. If you have such an authenticator, the server can say "give the owner of a passkey presenting a valid Enterprise Attestation for bob@example.com access to this account". But, again, FIDO isn't supposed to let random web sites on the Internet notice that two "different" users are actually using the same passkey (tracking users between web sites!), so you can't get the property you're looking for without Enterprise Attestation.