The document compares OpenID Connect (OIDC) and OAuth 2.0, explaining that OIDC is an authentication protocol built on OAuth 2.0 that generates id_tokens and is suitable for Single Sign-On (SSO), while OAuth 2.0 serves as an authorization protocol generating access_tokens. It outlines the authorization flow, including request structures for different app types, and describes various OIDC endpoints that handle user consent, token retrieval, and others. Additionally, the document covers the structure of JWT (JSON Web Tokens) indicating how signatures are generated and verified for secure communication.

1. twitter: @MithunShanbhag
blog: mithunshanbhag.github.io

2. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
OpenID Connect (OIDC) vs OAuth 2.0
OpenID Connection (OIDC)
• Authentication protocol (SSO)
• Built on OAuth 2.0
• Generates id_token
• Standardizedscopes
OAuth 2.0
• Authorization protocol
• Generates access_token
• Claimsandcustom claims
image attribution: okta dev blog

3. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
User Client App Authorization Server Resource (API)
Authorization request
Login button
302/Redirectto authentication prompt
Authentication and consent
Calls /authorize endpoint
• client_id: xxxxxxxxxxxx
• redirect_uri: xxxxxxxxxxxxxxx
• state:xxxxxxxxxxxxxxx
• response_type:tokenid_token
• scope: openid
Authorization grant
Requestresource(s)
• access_token
• id_token
• access_token
Response
Implicit Flow
LEGEND
FrontChannel
Back Channel

4. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
DEMO

5. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
AppType Channels User
Interaction
Client
Secret
response_type field Recommended Flow
Single Page Apps Front Yes No “token id_token” Implicit
Server-Side Web Apps Front, Back Yes Yes “code” Authorization Code
Native Apps Front, Back Yes Yes “code” Authorization Code/PKCE
CLI,daemons, services Back No Yes N/A Client Credentials
Legacy Apps Front, Back No No N/A Resource Owner/Password

6. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
User Client App Authorization Server Resource (API)
Authorization request
Login button
302/Redirectto authentication prompt
Authentication and consent
Calls /authorize endpoint
• client_id: {xxxxxxxxxxxx}
• redirect_uri: {xxxxxxxxxxxxxx}
• state:{xxxxxxxxxxxxxxx}
• response_type:code
• scope: openid
Authorization code grant
RequestID and Access tokens
code: {code}
Response
Authorization
Code Flow LEGEND
FrontChannel
Back Channel
Calls /token endpoint
• client_id: xxxxxxxxxxxx
• client_secret: xxxxxxxxxxxxxxx
• code: {code}
• id_token
• access_token
Requestresource(s)
Response
• access_token

7. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
OIDC Endpoints
• GET/authorize: Obtain user consent andauthorization grant.
• POST/token: Obtains id_token, access_token by supplying the authorization code or refresh_token.
• GET/userinfo: Obtains claims about the authenticated end user.
• POST/revoke: Revoke an access_token or refresh_token.
• GET/logout: Self-explanatory.
• GET/.well-known/keys: Obtain public keys (JWKS) used tosign the tokens.
• GET/.well-known/openid-configuration: Return OIDCmetadata related tothe specified authorization server.
• GET/.well-known/authorization-server: Return OAuth 2.0 metadata related tothe specified authorization server.

8. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
JWT Structure
HEADER
• Signing algorithm (mostly RS256/asymmetric orHS256/symmetric).
• Signing Key Id.
PAYLOAD
• Standardandcustom claims.
SIGNATURE
• HS256/symmetric:
• The client secret is used toboth sign & verify.
• Signature = HS256(base64UrlEncode(header)+ "." + base64UrlEncode(payload) + “.”+ secret)
• RS256/asymmetric:
• The private signing key/certificate is used tosign.
• Verification done via the public key (JWKS from/.well-known/keys OIDCendpoint).
• Signature = RS256(base64UrlEncode(header)+ "." + base64UrlEncode(payload) + “.”+ public/private key pair)

9. twitter: @MithunShanbhagblog: mithunshanbhag.github.io
Q&A