I’ll preface this post with the following.

• I learned about how great this trick is only a year and a half ago.
• It’s tricky to understand at first, but once you get it, you get it.
• I call this OAuth2.0/OIDC interchangeably in this post because web searches use these interchangeably too.

In traditional approaches, both human users and machines authenticate using some form of credentials like passwords or API keys/secrets. However, these methods expose a risk as they may be compromised by malicious actors. Regular rotation and updating the source of truth for these credentials can also become cumbersome in shared systems where multiple team members are involved.

OIDC Concepts and Roles

Client: A machine that requires authorized access to a resource server. This could be a mobile app, web application, or any other software that needs to interact with protected resources.

Resource Server: The machine providing the resource(s) the client needs.

Authenticator (usually Resource Server itself): A machine responsible for authenticating clients, verifying their legitimacy, and issuing temporary access tokens for authorized requests.

Identity: The client needs to be able to identify itself as an entity to the server, and the server should be able to validate that the client is indeed who they said they are.

With these definitions established, I’d like to now attempt to put all of these together.

• Someone who has the authority first goes and registers the client’s identity on the Authenticator. This is usually the action of a human being and is important. This specific actions is what allows the client to request authentication and authorization. The authorization is granted only to specific resources in the resource server. It’s not the keys to the kingdom.
• Client initiates an authentication request to the Authenticator with an identity, requesting access to select resource(s).
• Authenticator validates the identity, and confirms that the client is indeed allowed to access these resources, and provides temporary access through a token.
• The client uses the token to make authorized requests to the resource server.
• The resource server validates and confirms that the token is indeed valid and the resource being requested are authorized through the token.

This is what OIDC is. It’s a pretty powerful system, which seems confusing at first but is quite an elegant solution to the problem of managing credentials, toiling on keeping them up to date etc.

For the visual learners, here’s a visualization.