OAuth 2.0 & OpenID Connect

OpenID Connect (OIDC) for Authentication

1. Login the user in.
2. Making your accounts available in other systems.

OAuth for Authorization

1. Granting the access to your APIs.
2. Getting the access to user data in other systems.

Supported Use-cases

1. OpenID Connect
   • Web App login/ Web-SSO
   • Mobile App Login
2. OAuth
   • Delegated Authorization

OAuth Terminology

1. Authorization Server
   • Supports Authorize and Token Endpoints
   • During registration of clients:
     • Requires Redirect URI/ Callback URI.
     • Defines what Resources the client can request.
     • Allows to define Scope of Resources (eg: contacts.R, email.W, openid)
2. Resource Server
   • Actual resource for which client request on-behalf of user.
3. Authorization Grants
   • Authorization Code
     • Hit /authorize endpoint to get authorization_code and then /token endpoint to get AT.

       • /oauth/authorize?
         client_id=<client_id>&
         response_type=code&
         redirect_uri=<redirect_uri>&
         scope=<scope>
         -> <authorization_code>

       • /oauth/token?
         grant_type=authorization_code&
         code=<authorization_code>
         -> <AT>

   • Client Credentials 
     • Directly hit the /token endpoint to get AT.

       • /oauth/token?
         client_id=<Base64(client_id:secret)>&
         grant_type=client_credentials&
         scope=<scope>
         -> <AT>

   • Resource Owner Password Credentials
     • Directly hit the /token endpoint to get AT.

       • /oauth/token?
         grant_type=password&
         scope=<scope>&
         username=<username>&
         password=<password>
         -> <AT>

1. • Implicit
     • Response Type: token
   • Assertion
     • Response Type:
2. User Consent
   • User chosen/ consented and allowed scope which is requested by client to Authorization Server on-behalf of user.
3. Access Token
   • Token generated based on scope/ consent user chosen/ consented only.
   • Use token endpoint to send Authorization Code in exchange for AT.
   • Response Type: token
4. Refresh Token
   • Scope: offline_access
5. ID Token
   • Scope: openid
6. Bearer Token
   • Resource Server accepts the token whoever bearing and submitting the token.
7. JWT – JSON Web Tokens
   • All OAuth tokens are JWT format and has 3 components:
     1. Header
        • Algorithm (alg)
          • REQUIRED. Algorithm header parameter identifies the cryptographic algorithm used to secure the JWT. Example: RS256/ RS512/ HS256/ HS512.
        • x.509 certificate thumbprint (x5t/ x5t#S256)
          • A digest of X.509 certificate used to sign the JWT.
          • OPTIONAL. x.509 certificate thumbprint header parameter provides a base64url encoded SHA-256 thumbprint (a.k.a. digest) of the DER encoding of an X.509 certificate that can be used to match a certificate.
        • Key ID (kid)
          • OPTIONAL. Key ID header parameter is a hint indicating which specific key owned by the signer should be used to validate the signature. This is particularly useful when you have multiple keys to sign the tokens and you need to look up the right one to verify the signature. Example: SIGNING_KEY/ ENCRYPTION_KEY.
     2. Payload
        • Audience (aud)
        • Subject (sub)
        • Scope (scope)
        • Issuer (iss)
        • IssuedAt (iat)
        • Expiry (exp)
        • Auth_Time (auth_time)
        • Token Type (tok_type)
        • Client ID (client_id)
        • User ID (user_id)
        • Roles (roles)
     3. Signature

        • RSASHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload))

Type of Communication with AuthZ Server

1. Front Channel Communication 
   • JS client directly ask for AT instead of exchange the Authz code and then AT.
2. Back Channel Communication
   • Client provide client_id/ secret used to exchange the Authz code for a AT. (trust established between client and AuthZ server)

OAuth flows (grant type flows)

1. Authorization Code (front and back channels)
   • Web App with server back end.
   • Native mobile app – AuthZ Code flow with PKCE (proof-code for key exchange).
2. Client Credentials (back channel only)
   • Micro-services and APIs.
3. Implicit (front channel only)
   • JS App (SPA) with API back end
4. Resource Owner Password Credentials (back channel only)
   • Desktop clients such as GitHub client

Problems using OAuth for authentication

1. No standard way to get the user’s info
2. No common scope to get user’s info
3. Implementer headed for custom implementation to get user’s info, which is not consistent.

Open ID Connect (OIDC)

• Response Type: code + ID token.
• UserInfo endpoint for getting more user info.
• Standard set of scopes.
• Standardized implementation.

OAuth Proof Key for Code Exchange (PKCE)

• The Proof Key for Code Exchange (PKCE) extension describes a technique for public clients to mitigate the threat of having the authorization code intercepted.
• The attacker intercepts the authz_code returned from the authorization endpoint when a communication path not protected by Transport Layer Security (TLS).

• The technique involves the client first creating a secret, and then using that secret again when exchanging the authorization code for an access token.
• This way if the code is intercepted, it will not be useful since the token request relies on the initial secret.
• code_verifier – A cryptographically random string (43-128 character long) that is used to correlate the Authorization Request to the Access Token Requests.
• code_challenge – A hash derived from the code verifier that is sent in the Authorization Request, to be verified against later. [i.e.. t(code_verifier)]
• code_challenge_method – A method that was used to derive code challenge. Preferably ‘S256’ or plain
  • S256 code_challenge = BASE64URL-ENCODE(S256(ASCII(code_verifier))) – t(code_verifier)
  • plain code_challenge = code_verifier

Credits: Okta-Youtube link.