OAuth and OpenID Connect

OAuth 2.0 and OpenID Connect (OIDC) are two widely used protocols that work together to provide secure authentication and authorization on the web. While they serve different purposes, they are often used in conjunction with each other to ensure secure access to web resources.

OAuth 2.0 (RFC-6749)

OAuth 2.0 is an authorization framework that allows a user to grant a third-party application access to their resources without sharing their credentials. Instead, the user grants the application an access token, which allows the application to access the user's resources on their behalf. This protocol has become a standard for granting access to APIs, and it is used by many major companies, including Google, Facebook, and Microsoft.

By authorization, it means user is allowing a third-party application to perform an action on their behalf. It can be as simple as retrieving basic information to as complicated as posting social media post on user's behalf.

The OAuth 2.0 protocol consists of for components:

  • Resource Owner: The user who owns the resource being accessed.

  • Client: The application requesting access to the user's resources.

  • Authorization Server: The server that authenticates the user and issues an access token.

  • Resource Server: The server that hosts the protected resources that the client wants to access.

The client initiates the OAuth 2.0 flow by requesting authorization from the user. The user is redirected to the authorization server, where they are asked to authenticate and authorize the client's request. Once the user grants authorization, the authorization server issues an access token to the client, which the client can then use to request resources from the resource server.

          +--------+                               +---------------+
          |        |--(A)- Authorization Request ->|   Resource    |
          |        |                               |     Owner     |
          |        |<-(B)-- Authorization Grant ---|               |
          |        |                               +---------------+
          |        |
          |        |                               +---------------+
          |        |--(C)-- Authorization Grant -->| Authorization |
          | Client |                               |     Server    |
          |        |<-(D)----- Access Token -------|               |
          |        |                               +---------------+
          |        |
          |        |                               +---------------+
          |        |--(E)----- Access Token ------>|    Resource   |
          |        |                               |     Server    |
          |        |<-(F)--- Protected Resource ---|               |
          +--------+                               +---------------+

While OAuth 2.0 is about resource access and sharing, it does not provide proof of user authentication. Hence, OIDC is required for user authentication.

OpenID Connect (Specs)

OpenID Connect (OIDC) builds on top of OAuth 2.0 and adds an identity layer to the protocol. OIDC enables the client to obtain information about the user's identity, such as their name and email address. This is accomplished by adding an ID token to the OAuth 2.0 flow.

The OIDC protocol consists of several components:

  • Resource Owner: The user who owns the resource being accessed.

  • Client / Relying Party: The application requesting access to the user's resources.

  • Authorization Server / Identity Provider (IdP): The server that authenticates the user and issues an access token and ID token.

  • Resource Server: The server that hosts the protected resources that the client wants to access.

  • User Info Endpoint: A URL that the client can use to obtain additional information about the user's identity.

When the user grants authorization, the authorization server issues both an access token and an ID token to the client. The ID token contains information about the user's identity, which the client can use to personalize the user's experience. The User Info Endpoint is a URL that the client can use to obtain additional information about the user's identity.

The OIDC flow is similar to the OAuth 2.0 flow, with the addition of the ID token. The client initiates the flow by requesting authorization from the user. The user is redirected to the authorization server, where they are asked to authenticate and authorize the client's request. Once the user grants authorization, the authorization server issues both an access token and an ID token to the client. The client can then use the ID token to obtain information about the user's identity from the User Info Endpoint.

        +--------+                                   +--------+
        |        |                                   |        |
        |        |---------(1) AuthN Request-------->|        |
        |        |                                   |        |
        |        |  +--------+                       |        |
        |        |  |        |                       |        |
        |        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
        |        |  |  User  |                       |        |
        |   RP   |  |        |                       |  IdP   |
        |        |  +--------+                       |        |
        |        |                                   |        |
        |        |<--------(3) AuthN Response--------|        |
        |        |                                   |        |
        |        |---------(4) UserInfo Request----->|        |
        |        |                                   |        |
        |        |<--------(5) UserInfo Response-----|        |
        |        |                                   |        |
        +--------+                                   +--------+

In summary, OAuth 2.0 and OIDC are two protocols that work together to provide secure authentication and authorization on the web. OAuth 2.0 enables a user to grant a third-party application access to their resources without sharing their credentials, while OIDC adds an identity layer to the protocol, allowing the client to obtain information about the user's identity.

If you are interested in illustrated explanation, you can read this article.

Last updated