I went with using Keycloak for a platform I'm developing right now and it feels like a very overcomplicated enterprise piece of software - it still does work and has the features that I need (notably: an SSO login portal, user registration, password resets and social login), but definitely needed a certain amount of time to configure correctly and had odd bugs, like me needing the following in my reverse proxy configuration:<p><pre><code> SetEnv proxy-initial-not-pooled 1
SetEnv proxy-nokeepalive 1
</code></pre>
otherwise connections would randomly drop. I was looking for other ways to make development a bit easier and also settled on mod_auth_openidc, which is an Apache module that lets it act like a Relying Party and handle lots of the heavy lifting (protecting endpoints, refreshing tokens etc.) for me, and lets me work with just a few headers that are passed to the protected resources: <a href="https://github.com/OpenIDC/mod_auth_openidc">https://github.com/OpenIDC/mod_auth_openidc</a><p>It works, but I'm still not happy - I realize that there are many types of attacks that have historically been a problem and that certain OpenID Connect flows try to protect against, in addition to the fact that if I wrote my own security code it'd almost certainly be worse and have vulnerabilities (in the words of Eoin Woods: "Never invent security technology"), and it's a good thing to follow standards... but the whole thing is such a pain. Both OpenID Connect, Keycloak and configuring mod_auth_openidc.<p>Right now I'm moving permissions/roles back into the app DB, because I don't want to have to work with the Keycloak REST API every time I want to change what a user can or cannot do in the system, in addition to permissions which might only apply conditionally (one user might be related to multiple organizations, having different permissions in the context of each).<p>Regardless, it's nice that there are more pieces of software out there to choose from! Do manage your expectations when working with OpenID Connect, though.
Having built and worked with a variety of oidc implementations. It is an incredibly misused technology, while it initially can be easy to integrate into your app. It increases the complexity of the app to a surprising degree. Now suddenly your little webapp have to handle how various devices handle redirects to external sites, receives callbacks. And all the weird ways oidc implementations uses cookies, handles return urls, logouts, profiles etc.<p>I am not so sure the model of using a central oidc solution as the primary login to your app is such a good idea. There are so many failure points in just getting to and fro the oidc portal that can break in all sorts of ways, with no good way of debugging, leaving users stranded in the middle of redirects. Especially as logs are split between 3 parties, the browser, the client (server) and the oidc server.<p>I ripped out our oidc primary login and implemented comparable features in my current company (this is probably not for everyone though), it has vastly reduced support tickets, and generally been a faster and more intuitive solution, but more expensive, and requires more domain knowledge. Still I'd rather have that than having a team spend years handling support tickets for endless social login issues.<p>If you choose to use oidc, please, please only use it for social logins, don't do oidc within oidc within oidc (I am not exaggerating, I've seen 5 levels of nested oidc and oauth2 flows). Like a lot of these solutions such as Zitadel, Auth0, etc. It becomes a nightmare to support and mature.
Just two days ago I wrote a comprehensive tutorial on how openid connect works using simple http requests to understand the flow: <a href="https://spapas.github.io/2023/11/29/openid-connect-tutorial/" rel="nofollow noreferrer">https://spapas.github.io/2023/11/29/openid-connect-tutorial/</a><p>It has been written with keycloak as the auth server but should work for any proper openid connect implementation since I used the specification as a guide.
Nice. Once upon a time we created something like this. <a href="https://github.com/reddec/oidc-login">https://github.com/reddec/oidc-login</a> (Client only)
I would like to become more knowledgeable about authentication and identification tech stacks (LDAP, OIDC, Oauth, CAS, etc.) and have hands-on experience. I already dabbled a bit with some LDAP, I have professional experience in administering linux boxes and intranet infrastructure. Where should I begin if I want to set up a simple homelab with maybe a raspberry and some NUC ?
Oidc and keycloak have been great for my project. We stear users to it as it also allows for user impersonation by an admin. Thi is a huge help to debug issues for users, while also keeping any authentication work out of our app and the concern oof the authentication layer.<p>This alone sets it apart for us. Lots of other solutions don’t offer this. And then users make requests to our software for this ability and like I tell them, there’s no way our software is going to insert itself into your authentication system. That’s for your authentication system!!<p>Anyway, I seem to be the minority here but maybe that’s the domain I work in.
Is OpenID still in use much?<p>I come across it less and less. To the point where I get the feeling it's just some legacy implementions that have it, but nothing more.
I can't recommend enough Zitadel and its OIDC library. Code is very well-writen and informative.<p>Highly encourage everyone jump into source code and explore how IntrospectionResponse struct work with all related code around<p><a href="https://github.com/zitadel/oidc/blob/main/pkg/oidc/introspection.go">https://github.com/zitadel/oidc/blob/main/pkg/oidc/introspec...</a><p>// IntrospectionResponse implements RFC 7662, section 2.2 and<p>// OpenID Connect Core 1.0, section 5.1 (UserInfo).<p>// <a href="https://www.rfc-editor.org/rfc/rfc7662.html#section-2.2" rel="nofollow noreferrer">https://www.rfc-editor.org/rfc/rfc7662.html#section-2.2</a>.<p>// <a href="https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims" rel="nofollow noreferrer">https://openid.net/specs/openid-connect-core-1_0.html#Standa...</a>.<p>type IntrospectionResponse struct {
Active Scope ClientID TokenType ... exp iat nbf sub
Audience ... aud ...
JWTID ... Claims map[string]any
}<p>If you want to explore the difference between identity providers, click through<p><a href="https://github.com/nextauthjs/next-auth/tree/main/packages/core/src/providers">https://github.com/nextauthjs/next-auth/tree/main/packages/c...</a><p>Azure is the most insane ... and it's a lot of fun to compare them all against each other.<p>Next go though PKCE (Proof Key for Code Exchange) and look how code_challenge, code_verifier works or at least see interfaces .<p>Ory Fosite is a great alternative too
<a href="https://github.com/ory/fosite">https://github.com/ory/fosite</a><p>Support PKCE #59835 in x/oauth2
<a href="https://github.com/golang/go/issues/59835">https://github.com/golang/go/issues/59835</a><p>Scott Brady's content is great for undetstanding the topic<p>SPA Identity and Access Control with OpenID Connect <a href="https://www.youtube.com/watch?v=rP3St0GU_Bk" rel="nofollow noreferrer">https://www.youtube.com/watch?v=rP3St0GU_Bk</a>
OAuth is Not Authentication <a href="https://www.scottbrady91.com/oauth/oauth-is-not-authentication" rel="nofollow noreferrer">https://www.scottbrady91.com/oauth/oauth-is-not-authenticati...</a><p>SPA is a landmine ..<p>OAuth 2 0 and OpenID Connect for Single Page Applications Philippe De Ryck <a href="https://www.youtube.com/watch?v=XoBtUn4XczU" rel="nofollow noreferrer">https://www.youtube.com/watch?v=XoBtUn4XczU</a><p>The deeper you go into the topic the more you will discover. It's an ultimate "rabbit hole" - web, native, SPA flows, PKCE, JWT, session storage, custome middleware for your favorite flavor of backend framework, etc