Skip to main content

OAuth 2.0

Time before OAuth

Before OAuth was invented, a common way to give third-party application access to your account is to just provide them your password. This way of allowing third-party application accessing your account information of course have number of problems on the surface.

The application need to login as the "user" so they must store the password somewhere, and often just as plaintext, so if the application is somehow hacked then your account information can be easily stolen. In addition, the only way of revoking the access after you give the application your password is to change your password, which nobody likes to do.

Then many services realize how problematic this traditional way of user granting access to third-party application and people started developing ways to solve this problem.

OAuth 1.0 was formulated on August 2007 that was meant to solve this problem. Then OAuth 2.0 was started to simplify and clear up many of the problems that previous OAuth 1.0 had. Nowadays, OAuth 2.0 is the de facto standard for authorization (giving third-party application the privilege to access private resources on behalf of a user).

How does OAuth 2.0 work

Keep in mind that OAuth 2.0 is an authorization protocol not an authentication protocol (verifies that the user is who he/she claim she is).

OAuth 2.0 uses Access Token. Access Token is a piece of data that represent the authorization (the go ahead) to access resources on behalf of the user.

OAuth 2.0 roles

Because everyone likes role-playing:

  • Resource Owner: The user or the system that owns the protected resources and can grant access to them.
  • Client: The application that requires access to the protected resources. In order to access the protected resources, the client must hold and provide the appropriate Access Token.
  • Authorization Server: This is the server that receives request from the client that is asking for Access Tokens and issue them on successful authentication and consent by the resource owner. The authorization server give two endpoints, the authorization endpoint, this handles the authentication and consent of the user, and the token endpoint, which is where the client will go to get grants (a set of steps that client has to do in order to get resource access authorization) there are different kind of grants to handle how Access Token are granted.
  • Resource Server: The server that hold the protected user resources and will receive access requests from the client. It will check and validate the Access Token from the client before giving back the requested protected resources.
OAuth 2.0 scopes

Scopes defines the which resources that they are requesting, and whether it is read/write.

Flow of OAuth 2.0
  1. First client request authorization from the authorization server, and providing the client id and client secret of the application itself
  2. The authorization server authenticates the client and verifies that the requested scopes are permitted.
  3. The resource owner interact with the authorization server to grant access (the agreement from the user saying that I allow this application to access my protected resources)
  4. Then authorization server redirects back to the client with either authorization code or Access Token. With authorization code it will be used to exchange for an Access Token
  5. With Access Token, the client can request access to the protected resource from resource server.

 

 

 

 

 

 

 

 

 

 

Back to top