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.
Great work! If you wanna understand how Open ID Connect works using <i>only</i> HTTP requests/responses based on the specification (<a href="https://openid.net/specs/openid-connect-core-1_0.html" rel="nofollow">https://openid.net/specs/openid-connect-core-1_0.html</a>) I've written an article here: <a href="https://spapas.github.io/2023/11/29/openid-connect-tutorial/" rel="nofollow">https://spapas.github.io/2023/11/29/openid-connect-tutorial/</a>
I stopped spending mental cycles trying to parse these standards after taking myself on a ride with a completely DIY SAML service provider implementation.<p>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.<p>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.<p>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 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.<p>OIDC solves problems for OAuth2 like "every Identity Provider has different endpoints" with OpenID Connect Discovery (/.well-known/openid-configuration).
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.<p>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:<p>"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."<p>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.