▲ 107 points
back
92 comments
OIDC (and the rest of the OAuth umbrella of stuff) is one category where every time I have to work with the protocols I think "there must be a less confusing way" and then have a failure of imagination for a simpler way to accomplish the same thing. I think it's because the protocols are conceptually simple, but the cryptographic parts, especially the PKI parts, make them intricate to understand exactly who is attesting or validating exactly what.
What’s insane to me is that it feels like nobody has actually managed to make this easy for developers yet. If they have, I don’t know about them.
I would normally consider myself pretty competent, but I stood up my first fully featured website recently with logins and such, and it took me about 2 days of work to get AWS Cognito working (using their recommended USER_SRP_AUTH). That’s not including 3rd party login functionality from Google and friends.
Their documentation and UX is piss-poor unless you’re willing to onboard your entire project to Amplify and enter npm-hell, which I wasn’t. It’s almost like they don’t even want your business.
I looked into using Auth0 instead and it didn’t seem to be any easier. Better docs, seems like they’re actually written by someone who both understands the auth problem domain and how to explain it to those that don’t, but still complex.
Yet when I was finished finally getting everything to work, it seems like the kind of thing you could easily package into an off-the-shelf product. It’s just that existing products don’t do it. Like why the fuck is there a guide explaining how to write a lambda to convert access codes to refresh tokens and persist them via cookies? That should be part of the Cognito platform!
Honestly thinking of just starting my own auth SAAS with blackjack and hookers
Don't judge the identity server space by Cognito, I beg of you. There are a lot of other players out there (I work for FusionAuth, one of them) who are working to make this easier.
Most have not been abandoned the way Cognito has. (Funny video on the topic: https://www.youtube.com/watch?v=x70EypnAH1Y .)
I don't know why Cognito hasn't seen more improvement. From the outside, it seems like CIAM would be worth investing in as a cloud provider. Say what you will about Azure and GCP, they both have CIAM platforms that see more love than Cognito (Azure AD B2C, Firebase).
> What’s insane to me is that it feels like nobody has actually managed to make this easy for developers yet. If they have, I don’t know about them.
There are definitely folks making it easier to add login/logout to applications (I see some of them pop up in sibling comments, and we are working on that at FusionAuth as well). But some of these are component libraries to proprietary SaaS applications. In this case you lose some of the power and standardization of OIDC. That works great for some use cases and not so good for others. The nice thing about OIDC is that almost everyone works with it (or with SAML). Certainly more than proprietary session based authentication providers.
I will tell you that as we are trying to make authentication simpler at FusionAuth, we have customers coming to us with pretty complicated use cases around federation, scale, automation, permissions and more. It's a balance to try to appeal to the developer who just wants authentication to work as well as the sophisticated customer who has these complex needs.
> It's a balance to try to appeal to the developer who just wants authentication to work as well as the sophisticated customer who has these complex needs.
This sounds like there should be two solutions, one for the simpler case and one for the complex case, rather than trying to make one solution work for all use cases.
Have you tried WorkOS? (I work there.)
Makes it super easy to add SAML/SCIM to your app. https://workos.com/
We also recently launched https://www.authkit.com/
> "I work there"
You don't just work there, aren't you the founder? :)
Not yet, I’ll give it a look next time I hack on my site. “Stripe for auth” is exactly what I’m looking for, and I know I still have a lot of auth head bashing left before I ship.
I’ll say though, my personal “customer demographic” ATM is more along the lines of someone who wants to get working user signups and auth and then never think about it again - so mentioning SAML/OIDC building blocks is a bit of a turn off for me. The reason is that I’m a solo dev trying to ship a browser-based multiplayer game, which I assign a low (maybe 5%) probability of ever becoming something with multiple people working on/turning into a real business - so I need auth, but would prefer to spend as much time as possible on the game itself, and don’t have anybody to farm the work out to.
But I’m happy to give workos a shot to see if it makes my life easier.
I use Supabase just for auth (use AWS for everything else) and it was incredibly simple. The only issue is that their docs for my niche use-case were slightly out of date, but it still only took me maybe 30 minutes total.
I hand-wrote the largest OIDC deployment in the world, after experimenting with other libraries. It is awful. Do not use OpenID, do not use OIDC.
Do you have a recommendation on what to use instead?
The crypto isn't complicated. What makes it complicated is the 10,000 different use cases they want the solution to work for, rather than one solution per use case, and a loose coupling interface for all of them.
It’s not because of cryptography, but because of abusing technologies not made for interactive stateful applications (i.e. HTTP, HTML etc.) for interactive stateful applications.
I used to think this, but I’ve also worked on authentication/authorization in contexts where you’re not constrained to HTTP requests, and it doesn’t really get any less complex once federated identities, finer grained access control features, and revocation enter the mix.
Sure trying to do everything through JWT’s and cookies makes things harder, but reasoning about attestations by a user from one federated identity provider that a service from a different federated identity provider should be able to query specific data on behalf of the user is messy no matter where you do it, and every medium sized enterprise has that problem somewhere in the IT stack. At that point JWT is just another serialization format for passing attested data around.
I don't see how the display layer (HTML, CSS) or transport layer (http, TLS) are not suitable for mildly interactive stateful applications. All the state is on the server, except a few cookies.
What they are "abusing" is the fact that the same browser, under user's control, may have access to many sites which don't by default trust each other. The user can attest that they should.
No, it can indeed be vastly simpler to handle auth.
But you have to consider many complex aspects to provide a simple solution:
- What are your real use cases (authentication, authorization, delegation?)
- What is your threat model? (avoiding silly mistakes, preventing corporate espionage, defending against targeted attacks require very very different solutions)
- How to integrate into your ecosystem (tech stack, actors, layers..)
Then you might be able to remove some constraints. You might not need authorization delegation, stateless and readable json tokens.
But often it's easier to not think too much about it and just use "an industry proven standard", and that is oauth2 and OIDC:
a large auth umbrella to avoid looking at the sun.
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.
Great work! If you wanna understand how Open ID Connect works using only HTTP requests/responses based on the specification (https://openid.net/specs/openid-connect-core-1_0.html) I've written an article here: https://spapas.github.io/2023/11/29/openid-connect-tutorial/
Thanks, your article is what I was hoping for when I clicked the OP. I've been putting all my self hosted services behind OIDC recently using Authentic and I've been wanting to actually understand how the flow works under the hood, this really helped
Is it "keycloak.example.com" or "kc.example.gr"?
> ...and your keycloak server is hosted on https://keycloak.example.com. This realm will have a base url with the value: https://kc.example.gr/realms/sample-realm/...
Ah thanks for catching this!
I stopped spending mental cycles trying to parse these standards after taking myself on a ride with a completely DIY SAML service provider implementation.
Today, we use OIDC & SAML to authenticate all of the things. But, I cannot explain how any of it works in terms of detailed protocol, certificate chains, etc.
We actually have no in-house configuration along this axis because we only use products, such as web function runners, that live inside the IdP's platform. These can be trivially opted-in for MFA authentication with a single dropdown election if you are using Azure.
If your mission is to build your own IdP platform and/or SP client libraries, then it totally makes sense to dive into this rabbit hole. Otherwise, make it someone else's problem. An occasional headline in the news about a token not expiring in time, etc, is not worth chasing unless you intend to compete directly with these providers and build your own identity platform. If Microsoft can get it wrong sometimes, so will you.
I've been working with Pythons Social Auth, because I didn't want to spend brain power trying to figure out exactly how OIDC works. Still that isn't enough, because OIDC isn't always implemented the same.
E.g. Apparently you can return OIDC claims in two ways, nested or flat, but most clients do understand that, so if your server don't know how to do flat and your client only does flat, then you have a problem.
Yeah, lots of problems also come from JWT being a garbage Standard that doesn't actually standardize how to format a token.
I do not known why OIDC has so many bad comments here. At my $company we are using Keycloak for multi-realm (multi-tenant) authentication of users and clients (applications). Yes, the learning curve is long for OIDC and even longer for Keycloak. The FreeMaker Template Engine is awful compared to Twig. Updates of Keycloak can break something, so better have proper test/stagging environment. But this is the tax for not implement something, that is not in core domain of organization.
OIDC solves problems for OAuth2 like "every Identity Provider has different endpoints" with OpenID Connect Discovery (/.well-known/openid-configuration).
And then in real life I have to use the idm of 5 car manufacturers. Their devs being in South korea, China, US, Italy (we are in Germany).
Impossible to manage meetings. Impossible to adhere to the standard. Impossible to demand that they use the well-known config. Impossible to agree on a good UX (by using sane config values for token validity).
> OIDC solves problems for OAuth2 like "every Identity Provider has different endpoints" with OpenID Connect Discovery
Not really: https://www.rfc-editor.org/rfc/rfc8414.html
Maybe I am really missing something seeing how other comments didnt mention it, but is this REALLY explaining how OIDC works? I don't see it.
No. This is more like a "how to configure an OIDC integration between Github Actions & AWS" tutorial. It uses OIDC, but "How [OIDC] works" is too broad of a title for what the article ends up covering, IMO.
No, there's no explanation.
This doesn't really explain how OIDC works, it just explains the flow of requests a user would see if they're setting up OIDC for authentication between two systems for the first time.
But beyond that, I'd say in future blog posts it would look a bit more professional to use some kind of architecture diagram making software, rather than somebody's napkin drawings. It's a little more difficult than it needs to be deciphering these graphics. To be entirely honest, I'd settle for mspaint-level quality if none of the free diagram making tools out there catch your eye.
Since OP seems to be the website author... You should remove or alter the ::selection style in your CSS. In dark mode, selecting text makes it illegible (white on white).
This was a nice overview of why you'd use OIDC to get short lived access tokens (in the pure sense, not in the OAuth sense) with a heavy emphasis on AWS. Not really an overview of OIDC, though.
This is a really useful guide, but it's still not enough... every time I read something like this I get to a bit like this:
"Create a role on AWS, add trust policy specifying which github org+repo are allowed to access this AWS role. Create an identity provider for github actions."
I think need a full video of clicking around in the AWS console here, because the idea of having to figure out how to do that myself is horrifying to me.
I've seen the same issue with instructions for how to configure Keycloak as an OIDC provider - given Keycloak has so many options (some of which might well be security significant), you'd almost want a step by step explicit statement of what every setting should be, to get to a tested, validated and secure configuration.
Which flow and service/grant etc seems to matter a lot, and be a good example where you'd want a very clear playbook of step by step instructions that you can hand off to someone else to unambiguously follow.
I've been wanting to setup GitHub Actions to use OIDC with Google Cloud (for deploying to Cloud Run) for a couple of years now, but I find the documentation completely inscrutable: https://docs.github.com/en/actions/deployment/security-harde...
Jesus. We fucked with keycloak for like a minute at one of my past jobs where we used FreeIPA. Gave up, and just didn’t use that functionality beyond whatever default stuff it m if it do. IAM is hard. I kind of enjoy it, but there’s always a hundred other things I’m accountable for managing.
Enabling devs to do development work on their local machines with Keycloak in the stack is... fun /s.
It's not terribly difficult. I just threw a quick gist to help with this OIDC for Github in AWS - https://gist.github.com/sakopov/a66ef55f9713649e7d7b9b4a91d6...
Thanks for that, that's actually really useful - though I don't use cloudformation yet so I'd have to learn enough of that to put this into action.
Love that you have to just happen to know about "1b511abead59c6ce207077c0bf0e0043b1382612" as the magical "known thumbprint" for GitHub!
>I think need a full video of clicking around in the AWS console here, because the idea of having to figure out how to do that myself is horrifying to me.
Or even better, was CLI commands or terraform.
CLI commands would be OK. Terraform wouldn't, because then I'll have to learn enough Terraform to run it - I'd rather minimize the number of extra tools I have to figure out here.
True. Will try to add a loom video to this article
I've recently been looking into passkeys and it seems much simpler than this.
Passkeys and OIDC are not directly related. If all you want is "authenticate to AWS" then yes, passkeys would work, but so would a simple password, or a TLS client certificate, or whatever other technology you like for authentication.
OIDC works for things like "use my employer's login to get access to AWS resources without having a separate AWS password".
For certain OIDC authentication implementations, you can actually use passkeys. Standard passkeys should work perfectly fine with Keycloak's WebAuthn implementation, for example, either as a second factor or as the first factor in the login flow.
Personally, I would be worried about losing access to an account if I only relied on a passkey.
I don't really understand this problem. Just click the "forgot password" link (perhaps "lost passkey" for passkey-first services?).
How can I backup a passkey on a sheet of paper?