oAuth

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.

OAuth was actually intended to handle the Authorization. It was actually meant for a service to authorize another service.

Example:

• Document Printing Website [Client]
  • Once the User [Resource Owner] is Authenticated
  • The user can either upload a document [Resource] OR
  • Provide a google drive link [Resource Server] through which it can be retrieved
  • Now with the google drive link. Can the client download the document from google drive?
    • Yes, if it's shared. But that will make the document shared globally
    • No, because Google doesn't trust the Client
  • To solve this purpose, a standard OAuth has to be implemented by both the services
    • By Implementing the OAuth, google can give access to the Client to the User's data
    • But the User should give access to the Client to only download the documents nothing else (delete, create etc..)
    • So it should have restricted access and not the complete access
    • So this should be implemented by the google

Standard Versions

• OAuth 1
• OAuth 2

Process

• Google to implement the OAuth and have the accesses defined
• When user selects google drive to upload document
• Client asks google to download the file through the OAuth flow
• Google doesn't trust the Client and so requests the Users indicating the requested access from the Client
  • It also informs the User on all the permissions that the Client has requested for
• Once User validates this request, Google creates and sends the Client a Token* indicating that the Client has access tot he requested permission
• The Client uses the access token and requests for the document download access
• Google validates the Token and based on the Token Validity & it's permissions,
  • Rejects
  • Approves and sends the document

Terminology

• Document Printing service = Client
• Resource = Document
• Resource Owner = User
• Resource Server = Google

Responsibility

• So the burden of Authorizing lies with Google [Resource Server]. Typically the resource server is coupled with Authorization server.
• Google implements the Authorization Server. It can be in the same server as resource server OR can be a separate one
• The Authorization server's responsibility is to issue access token, basically the complete authorization
• The resource server's responsibility is to serve the resources

Flows - There are many flows/ways to have the oAuth implemented, few listed below

• Authorization Code Flow

  • User is logged in to Document Printing service, asks the service to print photo from Google Drive
  • Client knows that Google has implemented OAuth and so asks the Authorization server and requests for the document
  • Authorization server cannot trust the Client and so asks the Users to approve this request (along with what access is requested for)
  • User validates the request and allows the Client to access the document
  • Authorization server responds back to client indicating the approval & sends a "Authorization Token" (a short lived token)
  • Client uses the Authorization token and contacts the Authorization server for the access token
  • Auth Server validates the "Auth Token" and responds the Client with an "Access Token"
  • Client requests the Resource Server for the document along with the "Access Token"
  • The Client internally validates the token (either by itself OR with the Auth Server) and returns the document to the Client
  • Best option with more security

• Implicit Flow (Simplified)

  • User is logged in to Document Printing service, asks the service to print photo from Google Drive
  • Client knows that Google has implemented OAuth and so asks the Authorization server and requests for the document
  • Authorization server cannot trust the Client and so asks the Users to approve this request (along with what access is requested for)
  • User validates the request and allows the Client to access the document
  • Authorization server responds back to client indicating the approval & sends a "Access Token" (a short lived token)
  • Client requests the Resource Server for the document along with the "Access Token"
  • The Client internally validates the token (either by itself OR with the Auth Server) and returns the document to the Client
  • Primarily for short lived access token. Used with javascript apps. Less secured flow

• Client Credentials (b/w Services - Microservices)

  • Service_1 requests the Service_2_Auth_Server for the required access
  • Service_2_Auth_Server knows the Client and hence responds with an "Access Token"
  • Service_1 requests Service_2 for the data along with the access token
  • Service_2 validates the token and sends the requested data
  • Trust worthy Services.

OAuth for Authentication - Ideally OAuth was intended for Authorization. It was managed to have it work for Authentication

• Sign in with Google, Facebook etc..
• By doing so, the Client trusts the User based on the Authentication from Google
• Authentication is nothing but validating the Client for it's existence (validating the google's account)
• If that is the case why should I authenticate instead I will use Google's authentication (based on Google's reliability)

Note

Token* = A token is created by Google. Ex: JWT Token.