Designated Authentication - OAuth2.0

OAuth2.0 and OpenID - is one of the best videos (62 mins) on this topic - Highly recommended. This blog is just a quick summary (4 mins read) of it.

What is OAuth?

OAuth is a security standard where you give one application permission to access your data from another application i.e. you authorized one application to use data from another application on your behalf, without giving them your username and password. The steps to grant permission(s) or consent is often reffered to as authorization or delegated authorization. Permissions are scoped e.g. client can be given access to read your GMail contacts but cannot Read/Write your email. OAuth is not exactly used for user identification (who loggged in), instead its used to access API’s for resources like gmail contact list.

• You check-in to a hotel.
• At the front desk - You give your details like Passport and Reservation
• Front Desk would in turn - give you the Key Card i.e. Access Token
• You can use the Key Card to access your reserved Room

Here, the Front Desk is the Authentication Server - the key card is your Access token used to acess your Room (Resources API). The API doesn’t really care who is accessing the Resource as long as they have the access token.

OAuth Terminologies:

Lets assume you are giving Yelp access to your Gmail account contacts..

1. Resource Owner: Represent you the owner of the gmail account; who can give permission/authorize.
2. Client: Represent Yelp i.e. the application which would like to perform action on behalf of you.
3. Authorization Server: One who validates the gmail uname/password and authenticate - in this case accounts.google.com. Resource owner will already have an account with this server (gmail).
4. Resource Server: Server (API) which has the actual content/resources like contact list in this case contacts.google.com. Which client would talk to get the actual data.
5. Authorization Grant: Once authenticated an Authorizatiion Code or temporary code is sent back to he client. So, the client has been granted relevant access to the resource owners gmail contacts. This is short lived, this is used to inturn get the access token (long lived).
6. Redirect URI: Also known as Callback. It is the URI to which the response of Authentication #5 should be sent back to client #2
7. Access Token: Token/Key used by the Client to access all the resources of the owner; based on the authorized permissions.
8. Response Type: The type of information the client would like to receive e.g: code (authorization code)
9. Scope: Granular permission the client wants acess to like Read Contact, Read Profile basic info.
10. Consent: Whether the client can be given permission to access the requested information.
11. ClientID: Unique ID of the client, which is used to talk to the authorization server.
12. Client Secret: Secret Key - only the client and the auth server shares. Helps Client and Resource Server to share information secretly behind the scenes.

OAuth Flow:

Prerequisite:

Client and the Authorization Server should establish a working relationship. Both the “ClientID (AppID)” and “Client Secret(AppSecret)” are generated by the Authorization Server. The client ID would be used to uniquely identify the client. Its the responsibility of the client to ensure the “ClientSecret” is kept secret and its only know by client and authorization server. As there are the only means for the Auth Server to verify the client.

Actual Flow:

In this example, Yelp would want to authenticate a user based on GMail Authentication, and access Profile/Contacts information.

1. Client(Yelp) would make a request to Authenticate - to “Autorization Server” (accounts.google.com); as part of the request:
   1. “RedirectURI” is set to a callback URL of the client “yelp.com/callback”
   2. “Respose Type” is set to “Code”, so a auth code is sent back as response to 1.a
   3. “Client ID” and “Scope” (Profile/Contacts)
2. Auth Server pops up a dialog (mostly) - where user gets to enter the GMail credentials (uname/pass) and authenticate
3. Auth Server shows up a consent form - list the info access requested (like contacts, profile) - user gets to choose Yes or NO
4. Once concent(Yes) is given - an “Auth Code” is generated and sent back to the the client - to specifiied callback/redirectURI.
5. Then, the client sends the “Auth Code + ClientID + ClientSecret” to “Authorization Server” and gets back an “Access Token”
6. Using the “Access Token”, Client can contact the resource server (contacts.google.com) to get the actual resources (profile, contacts) of the user.

Reference: https://www.youtube.com/watch?v=aU9RsE4fcRM