What is the problem OAuth solves

Let us say a photo editing website wants to access a user’s google drive service (or Dropbox service) to save edited photos . How would the user authorize the photo editing website so that the website can access user’s google drive?

Solution 1
The user shares his/ her Google/Dropbox credentials with the photo editing website . The downside is that this would give the website un restricted access to the user’s google account.

Solution 2

• The photo editing website which wants access to user’s google drive or Dropbox will provide the user the option to save edited images in google/Dropbox

• Once the user selects the service where he wants to save photos (say google drive) the website directs the user’s request to Google’s authorization service ,essentially telling the Google authorization service : I want access to user’s google drive to store photos.

• Google authorization service responds to the user with

  • Account selection screen. ( in case the user has multiple accounts)
    
  • An authentication screen (to authenticate by entering user id and password if the user is not already logged in )
  • Finally the consent screen which asks the user if he wants to allow the photo editing service to connect to his google drive
    

• If the user presses “yes” and gives consent, then Google’s authorization service will redirect the user’s request to back the photo editing service with access token . (Not exactly , but more on this later)

• The photo editing service can now save user’s photos in google drive service by using this access token. Note that without this access token the photo editing service api request to google drive service will fail.

The above flow is a simplified view of the oauth flow .

Important roles in OAuth (explained based on above example)

• Client  : Client is the application that is trying to access user's data . In our exapmple it is the photo editing software which wants the user to authroize access to his google drive.
• Resource owner : Resource owner is the user who owns the data and authorizes access his data/action in the http service. 
• Resource server : The service which has user's/ resource owner's data ( in this examle google drive)
• Authorization server : The server which handles the authorization request .
• User Agent: :  Agent used by the Resource Owner to interact with the Client (eg , a browser or a native application)

Key points to note

• Note that the user’s Google user id and password were shared with Google’s authorization service. Not with the photo editing website
  So the user’s Google credentials are safe with google.

• Why did Google have a separate authorization service?

  • Google has a number of services and authorization capability INSIDE every service would be a bad idea. If authorization is abstracted out in a separate service then it would be more secure and maintainable as
    • Authorization and other services can evolve separately.
    • Each service is no longer responsible for maintaining a secure authorization capability. The service need not be aware of the best security practices of authentication and authorization.

• Also note that the request from photo editing service to authorization server was for a particular action (saving photos) and the user gives consent only for that action . When the photo editing service receives the access token
  it can use the access token only for the action / data the user has given consent for. So request to the authorization server is made with scope .
  The authorization server asks for the user’s consent based on scope sent with the initial request.

• Is oauth 2.0 an authentication or authorization protocol or both?
  Well it is first important to understand the difference between authentication and authorization.

  • Authentication is about who is accessing the system.
  • Authorization is about whether access is allowed or not.

  oauth 2.0 is only an authorization framework that enables enables a third-party application to obtain a limited access to an HTTP service.”

  The framework does not talk about authentication . The token which is received by third party application can be a bearer token .
  A Bearer Token is an opaque string, not intended to have any meaning to clients using it. The token can be used to access api , but the standards do not talk about any way to use the token to get user information like name / email. Note that the access token can be jwt token (hence being self contained and good for peformance as the resourse server does not need to go back to resouce server for token Validation).  OpenID Connect 1.0 is a layer on top of OAuth 2.0 framework to address authentication.