OpenID Connect Basics.txt

OpenID Connect Basics

OpenID -> OpenID Connect (OAuth 2.0)

OpenID Connect is a standard that defines how a client application communicates with an identity provider to identify a user
 ebay (3rd party client app) -> logs in with -> Apple ID (OpenID Provider)

Identity Provider (IdP) - an entity that manages user attributes and credentials

OpenID Connect builds an identity layer ON TOP of the OAuth 2.0 specification

OAuth 2.0 is authorization framework for access delegation


Typical Flow
----------------

1. User visits ebay.com and chooses "Sign In With Apple ID"
2. Client application "redirects" the user to Apple.com to authenticate
3. Client application is granted a ID token from Apple.com to pass back to ebay.com
4. User is granted access to ebay.com

Authentication flows - define ways how you can transport an ID token from one point to another


OAuth 2.0
--------------
- deals primarily with access delegation (without sharing credentials)

// The Four Grant Types

[ Client Credentials ]

[ Resource Owner Password ]

[ Authorization Code Flow]

1. Client app initiates an auth flow by redirecting the user to the authorization server (OpenID Provider)
2. User submits credentials via the browser
3. Browser sends POST request (with credentials) to the auth server 
4. Auth server redirects back to client app with an AUTHORIZATION CODE (via the browser)
5. Client app exchanges AUTHORIZATION CODE for an ACCESS TOKEN by communicating directly with the authorization server
6. Authorization server responds back with an ACCESS TOKEN

// Sample authorization request to the auth server
GET https://localhost:8085/oauth/authorize?
       response_type=code&  # indicates that an authorization code is expected as a response to this request
       client_id=12345678 # identifies the client to the auth server for config match
       redirect_uri=https://web.applicaiton.com/login
       
// Sample authorization response from the auth server
     https://web.application.com/login?code=hus83nn-8ujq6-7snuelq
       
   
// Sample token request after receiving authorization code
    https://localhost:8085/oauth/token
    Payload
     {
         grant_type=authorization_code&
         code=hus83nn-8ujq6-7snuelq
         client_id=12345678
         redirect_uri=https://web.applicaiton.com/login
     }
     
     
     // Sample token response 
     {
           "access_token":"de09bec4-a821-40c8-863a-104dddb30204",   
            "refresh_token":" heasdcu8-as3t-hdf67-vadt5-asdgahr7j3ty3",
            "token_type":"bearer",  
            "expires_in":3599
     }

[ Implicit Flow ]
- same as the authorization code flow, but the auth server responds to the authorization request immediately with an ACCESS TOKEN

// Sample authorization request to the auth server (implicit grant type)
  GET https://localhost:8085/oauth/authorize?    
      response_type=token&    # request an access token in response to this request
      client_id=application_id&    
      redirect_uri=https%3A%2F%2Fweb.application.domain%2Flogin
      
// Sample authorization response from the auth server (implicit grant type)      
      https://web.application.domain/login#access_token=jauej28slah2&   expires_in=3599&   token_type=bearer # URI fragment

[ Refresh Token ] 


// The Four Components of an OAuth 2.0 Grant Type
Authorization request 
Authorization response
Access Token request
Access Token response

// Token Types
bearer 
pop



Client App <-> User Agent (Browser) <->  Authorization Server (OpenID Provider)

[ Typical OAuth 2.0 Authorization Code Grant Type Flow ]
1. User visits coolphotos.com 
2. coolphotos.com initiates authorization grant request by redirecting the user to the autorization server (OpenID Provider) - Facebook
3. User authenticates via the browser
4. Browser sends credentials in the form of a POST request to the authorization server
5. Authorization server redirects the user back to coolphotos.com with an AUTHORIZATION CODE
6. coolphotos.com exchanges the AUTHORIZATION CODE for an ACCESS TOKEN (this is direct communication between the client app and auth server)
7. Authorization server sends back the ACCESS TOKEN
8. coolphotos.com can now access my photos from Facebook

The token does not does not identity me, the owner of the photos. The token permits access to the resource on behalf of the resource owner

The token that comes back at the end of a "Login w/ Facebook Flow" is not for client applicaiton, but rather for the consumption (or use) of the Facebook API. The client app should not try to decode the acces token or try to make intepret the meaning of it. It simply acts as a "ticket" for acces to an event (API)

The access tokens SCOPE defines what data can be returned from the API

OAuth 2.0 = authorization (what you can do)
OpenID Connect = authentication


OpenID Connect
----------------------
- extends OAuth 2.0 to be able to identify a user
- produces an ACCESS TOKEN and ID TOKEN in the form of a JWT (container)
- JWT's carry assertions (claims) about a particular user
- assertion (claim): a strong statement about someone or something


// The Four Components of an OpenID Authentication Flow
Authentication Request
Authentication Response
Token Request
Token Response

// The Four Authentication Flows

[ Implicit Flow ]
- most popular among Single Page Applications

1. User clicks "Login" in client app and initiates an implcit flow by redirecting the user to the auth server (OpenID Provider)
2. User submits credentials
3. Browser sends POST request (with credentials) to the auth server 
4. Auth server redirects user back to the client app with requested TOKENS in a URI fragment (via the browser)

// Example authorization request to the auth server (implicit grant type)

https://accounts.google.com/o/oauth2/v2/auth? 
    client_id=424911365001.apps.googleusercontent.com&     
    redirect_uri=https%3A//app.example.com/redirect_uri&     
    scope=openid email&.  # scope can be profile, email, address, or phone    
    login_hint=jdoe@example.com&      
    response_type=id_token token&. # auth server will return both an ID Token and Access Token
    state=Xd2u73hgj59435&     
    nonce=0394852-3190485-2490358  # generated by the client app and included in the auth request when the ID token is built
    response_mode=[query | fragment]




Attribute Assertion - based on a set of attributes
Authentication Assertion - based on how the OpenID provider authenticates the user during the flow (username/password, certificate, etc)
Authorization Assertion - based on a user's entitlement's (classfication designation, department, etc)


SAML 2.0 Web SSO
--------------------------
- still the most widely used standard for SSO
- most new greenfield applications today use OpenID Conenct instead
- started to fade as XML became less ideal in the early 2010s
- identity industry started looking for JSON based standard
- OpenID Connect filled this gap


Identity Federation
------------------------
- the process of sharing identity related data between two or more organizations
- when you log into eBay with you google account, google shares your identity attributes (stored in Google), with eBay
- google is "federating" my identity attributes to eBay
- federation can also happen within a single organization
- trust domain: the teams having control and governance over an application
- all apps controlled and governed by the same team fall under the same trust domain
- the most common way to establish trust among domains is via X509 certificates
- OpenID providers sign the attributes it shares with client apps using the certificate and client apps validate the signature using the public certificate if the OpenID Provider 

Corporate IT Department (Identity Owner + OpenID Provider)
  Marketing Department
    Application 1
  Engineerng Department
    Application 2 
    
[Federation Protocols]
OpenID Connect
SAML 2.0 Web SSO
WS-Federation
Central Authentication Service (CAS)




OpenID Connect Common Use Cases 
-------------------------------------------------
[ Login to Client Apps ]
- most popular
- support for client-side, server-side, mobile, smart TV)

[ Sharing Attributes ]
- client apps can request the attributes they need from an OpenID provider by using OAuth2.0 scopes 
- client apps can use this information (say a users email address or first name) to build a personalized experience 

[ Signup ]
- client apps can use OpenID Providers like Google and Apple to initiate a login flow with OpenID to sign up users
- at the end of the login flow the client app gets user attributes (email, name, phone number) from the OpenID Provider and will use those attributes to create a local account for the user in it's own user store

[ Federating Access To APIs ]
- OAuth 2.0 is the industry standard for securing access to APIs
- to access an API protected with OAuth 2.0 you need an access token from an issuer or OAuth 2.0 authroization server)


Popular Open Source OpenID Client Libraries
-------------------------------------------------------------
- Keycloak
- IdentityServer (.NET)


Popular Cloud-Based Identity Solutions w/ OpenID Support
-------------------------------------------------------------------------------
- Auth0
- Azure AD
- Okta
- OneLogin
- Ping One

client
821255145320-temc2cg7v6enmpq04m5binqaf87n9rgt.apps.googleusercontent.com
 secret 
JlSEGjQzrmCeudlN1zA8rYWa

https://accounts.google.com/o/oauth2/v2/auth?client_id=821255145320-temc2cg7v6enmpq04m5binqaf87n9rgt.apps.googleusercontent.com&redirect_uri=https://localhost:3000/redirect_uri&scope=openid%20profile&response_type=id_token%20token&state=caf7871khs872&nonce=89hj37b3gd3

https://localhost:3000/redirect_uri#state=caf7871khs872&access_token=ya29.a0ARrdaM_6vE6SI29yhXjflyf5Z0vRshLK8lvqA5nACiWzpCSxI08Rv5FbRhONWiCYHWmldAQLwdR6cp1ylYoKurswfyvGPs6Qjwe6LRYlPb8E92fCW3lirIygrQoQseCcTGd1OVcqcruUt18lhZsI1tCYV5l9&token_type=Bearer&expires_in=3599&scope=profile%20openid%20https://www.googleapis.com/auth/userinfo.profile&id_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjFiZjhhODRkM2VjZDc3ZTlmMmFkNWYwNmZmZDI2MDcwMWRkMDZkOTAiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJhenAiOiI4MjEyNTUxNDUzMjAtdGVtYzJjZzd2NmVubXBxMDRtNWJpbnFhZjg3bjlyZ3QuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJhdWQiOiI4MjEyNTUxNDUzMjAtdGVtYzJjZzd2NmVubXBxMDRtNWJpbnFhZjg3bjlyZ3QuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJzdWIiOiIxMDQxOTU0MTk3OTgxMDkwNzc0ODEiLCJhdF9oYXNoIjoiM1ZzMDZzM3VCYWFXTVVRWWVjVVliQSIsIm5vbmNlIjoiODloajM3YjNnZDMiLCJuYW1lIjoiTG93ZWxsIFdvb2RlbiIsInBpY3R1cmUiOiJodHRwczovL2xoMy5nb29nbGV1c2VyY29udGVudC5jb20vYS0vQU9oMTRHajUtMHdBb1Q0X281eUwxQWR2dzcyS1ZhUnhKd1p0bFludHlHVkFTQT1zOTYtYyIsImdpdmVuX25hbWUiOiJMb3dlbGwiLCJmYW1pbHlfbmFtZSI6Ildvb2RlbiIsImxvY2FsZSI6ImVuIiwiaWF0IjoxNjI2MzAxMTg2LCJleHAiOjE2MjYzMDQ3ODYsImp0aSI6IjM4NzQzNWI0Y2M3OTFjNDdiMDMwZTlmMjBkMmNjZWRiZjZhOGYxY2EifQ.HTIMD3r6dqS31uQ3A_ZOrc0fzM6ABiDszbsuvEfCkJk2JYRmvf2L-ea3hv4xPZhuvN_R7XUPmFnNT3k-CDPP6-DrLh-4PDw7EFsDUkUgHTOVe8OrycwWvRPiDMMWaXePR1eGDJh7dknlwN1aUdSl6Mo1P472gu5HFZmxA-l8YwA3BhK4jNQlNxZphA8ckCfi95nsn7oXvFaE8yVqdnj9pgWDG8y-YxbOWZn8CiW5WZeN2UFOoElLIDpc0ETI7NfuNT7FY--r11TMdNPjMxVu6tu3aW_klrSkgWjzVuHAw6VspIKVnJLVjZxfrjD_3O3p6KF2CtkdyT7plvTGTc6ilQ&authuser=0&prompt=consent