OAuth 2.0 and OpenID protocol

Posted on:May 29, 2024 at 03:14 AM

Table of contents

Open Table of contents

Protocol in short

1. OAuth workflow

https://oauth.net/2

Untitled.png

❗**How OAuth do authorization?**

Authorization server create a secret for resource owner

Resource owner grant this secret to client

Client ask Authorization Server with this secret for access token

Client use access token to access Resource Server, Resource Server verify access token locally(use Authorization Server’s public key)

2. OpenID Connect

OpenID Connect (OIDC) is part of the implementation of OAuth2, steps1.1 - 2.2

Untitled.png

❗**How OIDC do authorization?**

While OAuth 2.0 is about resource access and sharing, OIDC is about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where you log in, and then taken back to the website. For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google sends information back to Auth0 about the user and the authentication performed. This information is returned in a JWT. You’ll receive an access token and if requested, an ID token.

Workload Identity Federation

Workload identity federation is a new authorization method, used in Google Cloud, AWS, Azure.

Comparing to secret auth/cert auth which requires the resource owner to maintain secrets that leads to security risks of secret exposure, secret expiration, Workload Identity Federation introduce a third party role, Identity Provider(IdP), to provide token and authentication service.

Workflow In short:

  • Client acquires token from IdP(Client is managed by IdP so it could fetch token directly);
  • Client sends token to Resource Server
  • Resource Server ask IdP to validate this token(IdP service has been registered in Resource Service as Issuer URL)

https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation#how-it-works

  1. The external workload (such as a GitHub Actions workflow) requests a token from the external IdP (such as GitHub).
  2. The external IdP issues a token to the external workload.
  3. The external workload (the sign in action in a GitHub workflow, for example) sends the token to Microsoft identity platform and requests an access token.
  4. Microsoft identity platform checks the trust relationship on the user-assigned managed identity or app registration and validates the external token against the OpenID Connect (OIDC) issuer URL on the external IdP.
  5. When the checks are satisfied, Microsoft identity platform issues an access token to the external workload.
  6. The external workload accesses Microsoft Entra protected resources using the access token from Microsoft identity platform. A GitHub Actions workflow, for example, uses the access token to publish a web app to Azure App Service.

3. SAML / SSO

SAML = Security Assertion Markup Language

SSO = Single Sign-on

Untitled.png

Service Provider and Identity Provider has a trusted relationship

Token Grant Flow

Take Microsoft identity platform as example

1. Authorization Code Grant

Untitled.png

2. Implicit Grant

Untitled.png

3. Resource Owner Password Credentials Grant

Untitled.png

4. Client Credentials Grant

Untitled.png

Token usage

Use Access Token to Call Resource Provider

https://auth0.com/docs/secure/tokens/access-tokens/use-access-tokens

Transmit the access token to the API via Header Authorization

GET /calendar/v1/events
    Host: api.example.com
    
    Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL2V4YW1wbGUuYXV0aDAuY29tLyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL2NhbGFuZGFyL3YxLyIsInN1YiI6InVzcl8xMjMiLCJpYXQiOjE0NTg3ODU3OTYsImV4cCI6MTQ1ODg3MjE5Nn0.CA7eaHjIHz5NxeIJoFK9krqaeZrPLwmMmgI_XiQiIkQ

Resource Provider Validate Access Token

https://auth0.com/docs/secure/tokens/access-tokens/validate-access-tokens

JWT Validation

Untitled.png

Claim validation