Identity, authentication and authorization
2 likes499 views
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.
Identity, authentication and authorization
- 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
- 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)
Editor's Notes
- #5: angular app (angular app) Fiddler jwt.io
- #6: PKCE: Proof key for code exchange Code verifier, code challenge Client Credentials: Directly call the /token endpoint with client id + client secret, get access_token back Resource Owner Password: Directly call the /token endpoint with usernam + password, get access_token back