Last week, I wanted to learn the IAM pillar of OAuth2.0 and how the OAuth2.0 + OIDC authorization framework actually works. I talked with my mate (ChatGPT) about how it actually works. I understood the core idea of the authorization framework and how it plugs into the backend with our own existing system.

I know I could have generated it using a single prompt with Claude Opus 4.6, but my purpose is not to just look at things being made. I wanted to implement it from scratch.

The Golang code (because I am familiar with Go) I built from scratch, the link is here.

github repo »» https://github.com/devshehan/go-oauth2-oidc

What does OAuth2 solve?

OAuth2.0 + OIDC is an authorization framework. Instead of taking the user’s password and credentials, we can build backend systems that plug into an authorization provider (Google, GitHub).

In this framework, there are 4 major components:

  1. Resource Owner – Who actually wants to log in to the system
  2. Client – Who actually needs to be authorized
  3. Authorization Server – Who is going to authorize the user
  4. Resource Server – Where the actual resource owner’s data is stored

OAuth2.0 and OIDC main components and flow

How does the flow work?

Using the Web UI, basically the user clicks the “Sign up with Google” button. This means instead of manually logging into the server, the Resource Owner (user) wants to access the system without giving passwords to the server.

When the user clicks that button, it sends a request to the backend, and the backend redirects the request to the authorization server.

At this step, the server needs to send the following details:

  1. Redirect URL – Because the authorization server needs to connect back to the server
  2. Scope – The server should request what scope of data is required (profile, email, openid)
  3. State – A randomly generated value stored in the backend. During the authorization callback step, it is used to track communication between the server and the authorization server

Then the authorization server connects with the user and asks for permission. When those permissions are allowed, the authorization server hits the redirect callback.

In this callback, it includes the state we attached and also includes the authorization code.

Using this code in the callback operation, we can exchange the code for a token. At this stage, the authorization server gets the details from the resource server and exchanges them with our server. This is the token we actually need.

Inside that token, it includes the access token, id_token, and refresh_token. Based on the server requirements, we can use these tokens to handle the user inside the server.

At first, I also had a problem understanding whether we can use this id_token for our own server backend flow. No, we should not. After a long discussion with my mate (GPT), I understood that the server should not depend directly on the token provided by Google.

In my opinion, we should build the backend server to support stateless authentication and authorization flow, and then plug the OAuth2-OIDC framework into it.

This way, the entire server does not depend on a third-party authorization provider and can manage users internally.