Earlier in 2010's:
Identity/User Use Cases:
- Simple Login - Using Forms and Cookies:
Classic simple Authentication in Web App: Web Application -> Through Forms takes UserName and PWD -> Hashes and stores the digest in database against that user. User logged in through the forms -> Server compares the login credentials against the Hash stored for that user in DB.
If the credentials matches, creates a session Id for that user and returns the same as Cookies in HTTP response header. The browser stores this session Id and uses this for the subsequent request to the server.
What is Cookies?
https://www.youtube.com/watch?v=V0pzXU6FbQA
What is Session, Cookies and Tokens?
https://www.youtube.com/watch?v=GhrvZ5nUWNg
Drawbacks: Security and Maintenance to be handled by the Web Server.
- Single Sign On - Using SAML
New Use Case
-
Mobile app login - new use case: To login and remains logged in even if app runs background.
-
Delegated Authorization - Earlier implementation's problems?
Delegated Authorization with OAuth:
- User uses a WebApp(Ex-yelp.com) which wants to access user contacts.
- WebApp asks user for permission to read user contacts in GMail
- User wishes to grant access to Yelp to access ONLY GMail contacts.
- User hits Connect With Google, to give yelp permission to access google contacts. Yelp will launch Google's login screen for user. Here, yelp will specify Google what Info should it needs access to.
- When the user given the credentials, Google will explicitly inform the user that the app needs access to Google contacts. Should it allow or block.
- If user allows, then the yelp is authorized to access only the Contacts from Google. Please be noted, that yelp will have access to get data from only Google's Contacts API.
When User clicks "Connect to Google" in Web App page, OAuth flow begins:
OAuth Flow 2.0 Participants :
-
Resource Owner: Owner of the data that the application wants to access. Ex: User.
-
Client: Application that wants to get the data. Ex: Yelp
-
Authorization server: System to which we say to give permission to client. Ex: Google
Resource Server: API/Server which has the data. Ex: google.contacts.com Authorization Server and Resource Server can be the same. And it can also be different. todo:Find Ex?
- Authorization grant: OAuth communication flow,
"Yelp -> Google -> Yelp" : "Yelp asks permission for something -> Google asks user(Yes or No) -> Yelp may (or may not) gets permission"
In this flow, user's permission to Yelp's request to access (only)google contacts is granted via a token called "Authorization Grant" by Google. (todo. Find what happens if user says no? ie. What is Google's response back to yelp when the user clicks no?).
Authorization Grant Types:
-
Redirect URI: When user grants permission, Authorization Server along with Authorization token gives (URI)information about where it needs to look for the requested data to the client. It is called Redirect URI/Callback. Yelp uses this URI to access the requested data.
-
Access token: Client needs Access Token - a "Key", which client uses to access data from the Resource Server. This access token is restricted to use only for the scope for which it has been created for. For Ex. If Client request for reading user calendar, then the access token generated by the administraction server is valid for reading user calendar api. i.e, it cannot even use the same access token for writing to calendar api or for any other operation to the calendar. Also, cant be used for fetching any other user related info - contacts, persontal profile etc.
-
Scope: Defines what permission does the client have - Ex:Only Read Contacts/Email or Read and Write Contacts/Email Or Only write Contacts/Email etc. Can have list of scopes - todo. find ex? Administraction Server defines the scope.
-
Consent: What is the user choice for each scope.
Why Authorization Code first and then token? Why not token directly?
- Back Channel (highly secure channel) Ex. Our Backend server to other server. Only Our code is exectued
10.Front Channel (less secure channel) Ex. From Browser to our web server. Chances are there that someone can change the app in the browser and raises requst to the server.
Authorization Code Flow/Grant Type:
-
Authorization Grant - Uses both Front and Back Channel https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow <= without PKCE version
-
Implicit Flow - Only uses Front channel. Ex. React App without webserver only uses Web Browser so the token is retrieved via Front channel. Less Secure. But, this is the only way to get the token. TODO: How this case can be more secure.
-
Resource owner password credentials - Uses Only Back Channel - No Browser UI. Used for older applications. Not required for model app
-
Client Credentials - Uses Only Back Channel - No Browser UI. machine to machine communication. Ex: Comms between microservices.
OAuth is only created to Authorize the data to a user. i.e, if a client can access the data or not. It will not authenticate i.e is the client really a client who he claims to be? But, Each App started using OAuth along with their own implementation for authenticating the user. OAuth cannot be used for Authenticating the user.
Later on, seeing the need for authentication, OpenID Connect is created - An extension to OAuth 2.0. Use OpenID Connect for Authenticating the user.
- Requests ID Token(JWT token) - has user information.
- UserInfo End point for retrieving more user Info