Understanding OAuth 2.0 and OpenID Connect

#oauth #security #webdev #identity

OAuth 2.0

OAuth 2.0 is an authorization protocol that allows a client application to access a user's resources with limited permissions.

Background: Why OAuth 2.0 was introduced

In this article, the term “service” refers to the Client in the OAuth 2.0 context.

Let’s say a service (the Client) supports Google login, and it needs access to the logged-in user's contact list.

If OAuth 2.0 didn't exist, the service (Client) would have to log in to Google using the user’s (Resource Owner) own ID and password, just like the user would.

In other words, the service (Client) would have to ask for the user's password.

Obviously, this is not acceptable in real-world services.

A protocol was needed to allow the service (Client) to access the user’s Google contacts without ever knowing the user's password.

That’s the background behind the creation of OAuth 2.0.

How OAuth 2.0 works

Since only the user (Resource Owner) should know their Google password, only the user should log in to Google.

So, the service (Client) must provide an interface that lets the user log in to Google directly, and during that process, ask for permission to access the user’s Google resources.

📌 This sequence diagram is written in Mermaid syntax.

Unfortunately, dev.to does not support rendering Mermaid diagrams directly.

You can view the full visual version here on Notion.

sequenceDiagram 
    box blue FrontChannel
        participant Client
        participant Google
        participant Resource Owner
    end
    box red BackChannel
        participant Client's Server
        participant Google's Authorization Server
        participant Google's Resource Server
    end
    Client->>Resource Owner: Provide an interface like "Login with Google"
    Resource Owner ->> Google: Redirected to Google login page
    Google->>Resource Owner: Ask for consent to access resources in the given scope
    Resource Owner->>Google: Give consent
    Google->>Client: Redirect to pre-registered redirect URI or callback URL with an authorization code (OAuth 2.0 Authorization Grant)
    Client->>Client's Server: Send the authorization code received from Google to the backend server

    Client's Server-->Google's Authorization Server: Send the code along with the client secret issued by Google
    Google's Authorization Server-->Client's Server: If valid, issue an access token
    Client's Server-->Google's Resource Server: Use the access token to access user resources on Google

OpenID Connect

In OAuth 2.0, the client (Client) can gain access to a user's resources,
but it is not guaranteed to know who the user is (i.e., no identity information is provided by default).

It’s technically possible to include scopes that return some identity-related info,
but that’s more of a workaround — not a proper authentication mechanism.

OpenID Connect (OIDC) was introduced to solve this problem.
It extends OAuth 2.0 to handle user authentication properly.

How OpenID Connect works

If you include the openid scope in your OAuth 2.0 request,
Google’s authorization server will return not only an access token but also an ID token.

The ID token is a JWT (JSON Web Token) that contains identity information such as email, name, etc.
By verifying or decoding this token, the client can securely identify the user.

DEV Community