Re:How Open ID Connect Works
by jeroenhd on Thursday January 04, 2024 @04:58PM
(#38872858)
If you're writing software to authenticate users, the protocol is huge and complicated. That's why there are full prebuilt containers and SaaS authentication services that solve this problem. There are entire server implementations you can extend, but with tools like Zitadel and Keycloak ready to be configured and deployed for all manner of use cases, I don't see why you would.
If you're just authenticating your client app against a server, it's pretty easy (all you need is two tokens and a URL for most librarlies). With some web servers (Apache, Caddy, the paid version of nginx) you can put that config in a location block and have it deal with the entire auth flow, so all your application needs to do is take the REMOTE_USER header or call /whoami to find out who the user is logged in as.
Doing auth correctly is just hard. Personally, I treat it like I treat dates/times: use something someone else made, unless you have a particularly weird use case that nobody else supports.
If you're just authenticating your client app against a server, it's pretty easy (all you need is two tokens and a URL for most librarlies). With some web servers (Apache, Caddy, the paid version of nginx) you can put that config in a location block and have it deal with the entire auth flow, so all your application needs to do is take the REMOTE_USER header or call /whoami to find out who the user is logged in as.
Doing auth correctly is just hard. Personally, I treat it like I treat dates/times: use something someone else made, unless you have a particularly weird use case that nobody else supports.