I was going to comment „but I can already do a lot of that with Authelia and it is very simple to configure“, but then I found your very good comparison page - good comparison! I know the Authelia team is hard at working supporting some of the use cases that are currently not supported, so I will probably wait until some things are implemented there instead of switching.
Show HN: Obligator – An OpenID Connect server for self-hosters
81–90 of 134 posts
Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#82[deleted]
Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#83I could recommend https://github.com/panva/node-oidc-provider supports most of the oidc/oauth 2 rabbit hole specs.
Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#84Earlier quoted context omitted.
If you believe email to be the weakest link in the chain, then you have to get rid of email password resets too and use reset codes instead. Lose your codes, lose your account.
This. As sad as it is, email is the defacto identity on the internet. Every system I'm aware of falls back on email and/or phone numbers for recovery.
I.e. try to log into a gmail account from a new machine in an unfamiliar location, even if you know the password and can receive SMS codes.
So right now, I'm more worried about getting locked out of a mail account than that someone else could take it over.
As for unencrypted SMPT, there is SMTPS [1]. I'm not sure if this seever supports it, but I'd assume it would be a basic requirement if you want to communicate with real-world mailboxes and not instantly flagged as spam.
Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#85Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#86Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#87I'm on mobile, so haven't really checked where we differ in details.
Re: Show HN: Obligator – An OpenID Connect server for self-hosters
#88Earlier quoted context omitted.
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 - 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. htt…
> 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…
"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.