Källa: ByteByteGo Newsletter |

OAuth 2.0 and OpenID Connect (OIDC)

​​While OAuth 2.0 is primarily an authorization framework, it can be used in conjunction with OpenID Connect (OIDC) for authentication purposes. OIDC is an authentication layer built on top of OAuth 2.0, enabling the verification of a user’s identity and granting controlled access to protected resources.

When using ”Sign in with Google” or similar features, OAuth 2.0 and OIDC work together to streamline the authentication process. OIDC provides user identity data in the form of a standardized JSON Web Token (JWT). This token contains information about the authenticated user, allowing the third-party application to create a user profile without requiring a separate registration process.

In this setup, OAuth 2.0 provides ”secure delegated access” by issuing short-lived tokens instead of passwords, allowing third-party services to access protected resources with the resource owner’s permission. This method enhances security, as the third-party service does not handle or store the user’s password directly.

The diagram below shows how the protocol works in the “Sign in with Google” scenario.

In the “Sign in with Google” example, OAuth 2.0 defines four roles:

  1. Resource owner: The end user, who controls access to their personal data.
  2. Resource server: The Google server hosting user profiles as protected resources. It uses access tokens to respond to protected resource requests, ensuring that only authorized services can access the data.
  3. Client: The device (PC or smartphone) making requests on behalf of the resource owner. This device represents the third-party application seeking access to the user’s data.
  4. Authorization server: The Google authorization server that issues tokens to clients, managing the secure exchange of tokens between the resource server and the client.

OAuth 2.0 offers four types of authorization grants to accommodate different situations:

  1. Authorization code grant: The most complete and versatile mode, suitable for most application types. More details below.
  2. Implicit grant: Designed for applications with only a frontend, such as single-page applications or mobile apps. This is no longer recommended. More details below.
  3. Resource owner password credentials grant: Used when users trust a third-party application with their credentials, such as a trusted mobile app.
  4. Client credentials grant: Suitable for cases without a frontend, like command-line tools or server-to-server communication, where resource owner interaction is not needed.

The standard provides multiple modes to cater to different application scenarios and requirements, ensuring flexibility and adaptability for diverse situations.

The authorization code grant is one example worth examining. The specifications for the other three grant types are available in RFC-6749.