OAuth2

What is Authentication?

• Authentication is the process of proving your own identity to third party service. 
• It verifies whether a person’s identity is the same as he or she had declared himself or herself to be.
• So when we are trying to log in to Facebook or Google, we are required to first enter the email and password to verify our identity.

• Validating that users are whom they claim to be.
  • Username/password
  • Tokens
  • Bio-metrics

What is Authorization?

• Authorization is the process of giving someone permission to do something or have something. 
• In this process, a person grants another person to have some of its resources or use some of its resources.
• It is done after successful Authentication. 
• Here an Authorization server is providing access to third-party services to use some of its resources.

• It is a process of granting the user permission to access a specific resource.

• Eg:
  • Customer should be able to view their own payment.

What is OAuth2 means?

• OAuth 2.0 means “Open Authorization.
• It’s an open standard for authorization
• It allows an application to access resources hosted by another application on behalf of a user.
• It enables applications to obtain limited access to user accounts on an HTTP service
• It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. 
• OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.

OAuth2 Roles

• Resource Owner:
  • The user or system that owns the protected resources and can grant access to them.
    • An entity capable of granting access to a protected resource. 
    • When the resource owner is a person, it is referred to as an end-user.
      • eg: the user who is going to use that application.
• Client:
  • The client is the system that requires access to the protected resources. To access resources, the Client must hold the appropriate Access Token.
    • An application making protected resource requests on behalf of the resource owner and with his authorization. 
    • The term “client” does not imply any particular implementation characteristics
      • e.g: whether the application executes on a server, a desktop, or other devices
• Authorization Server:
  • This server receives requests from the Client for Access Tokens and issues them upon successful authentication and consent by the Resource Owner. The authorization server exposes two endpoints: the Authorization endpoint, which handles the interactive authentication and consent of the user, and the Token endpoint, which is involved in a machine to machine interaction.
    • The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.
      • eg: Google, Facebook etc.
• Resource Server:
  • A server that protects the user’s resources and receives access requests from the Client. It accepts and validates an Access Token from the Client and returns the appropriate resources to it.
    •  eg: Dropbox, GoogleDrive etc.

Flow

1. The application requests authorization to access service resources from the user
2. If the user authorized the request, the application receives an authorization grant
3. The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
4. If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete.
5. The application requests the resource from the resource server (API) and presents the access token for authentication
6. If the access token is valid, the resource server (API) serves the resource to the application

Authorization Grant

• Authorization Code: used with server-side Applications
• Implicit: used with Mobile Apps or Web Applications (applications that run on the user’s device)
• Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
• Client Credentials: used with Applications API access

OAuth Tokens

• Access tokens 
  • The client uses to access the Resource Server (API).
  • They have very short lifetime i.e they expire within some minutes or hours.
• Refresh Tokens 
  • The client uses to get a new Access token.
  • Their lifetime is much longer than access tokens i.e days, month and years.

Refresh token

The access token provided by any other grant flow has an expiration time. The client can use the refresh token as a grant to fetch the access token after the access token is expired.

A refresh token generally has a longer expiry duration. With the refresh token, the client can get the access token without reauthorization from the resource owner.

The client needs to provide refresh_token, client_id and client_secret while using this flow.

URL: https://auth-server.com/token
request params:
grant_type: refresh_token
client_id: 29352915982374239857
client_secret: uf1ie98f2kda2vu25uye3k1h

The response of API is the same as the access token.

Client Credential grant

This auth flow is used to grant the token outside the context of a user. The trusted client can use this to access resources that are not related to a user.

URL: https://auth-server.com/token
request params:
grant_type: client_credential
client_id: 29352915982374239857
client_secret: uf1ie98f2kda2vu25uye3k1h

The response of API is the same as the access token

Get Authorization Code

URL: https://auth-server.com/auth
request params:
response_type=code
client_id=29352915982374239857
redirect_uri=https://client.com/redirect
scope=create+delete
state=xcoiv98y2kd22vusuye3kch

With the above request, code is returned in response to the provided redirect URL.

Exchange Code for a Token

URL: https://auth-server.com/token
request params:
code: nao1n3f
grant_type: authorization_code
client_id: 29352915982374239857
client_secret: uf1ie98f2kda2vu25uye3k1h

The response of the API will provide a token:

{
"access_token":"K1Z04lLdZ1S0pIMF09DI1FTZjJ1jmOO06",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IzH6bFh6laf6gQ6TgA3sj19mfgA5egZx9a",
"scope":"create delete"
}

The client can use the “ access_token” to access the resource.

Advantages of OAuth 2.0

1. This flexible protocol relies on SSL (Secure Sockets Layer) to ensure data between the web server and browsers remain private to save user access token.
2. SSL uses cryptography industry protocols to keep data safe.
3. It allows limited access to the user’s data and allows accessing when authorization tokens expire.
4. It is easy to implement and provides strong authentication.
   • In addition to the two-factor authentication, tokens can be revoked if necessary
5. Uses single sign on
6. It has ability to share data for users without having to release personal information.

Disadvantages of OAuth 2.0

1. If you are adding more extension at the ends in the specification, it will produce a wide range of non-interoperable implementations.
   • you have to write separate pieces of code for Facebook, Google
2. There is no common format, as a result, each service requires its own implementation.
3. In the process of user verification, sometimes you have to make additional requests to get minimal user information.
   • It can be solved with the help of JWT token, but not all services support it.
4. When a token is stolen, an attacker gains access to the secure data for a while.
   • To minimize this risk a token with signature can be used.
5. If your favorite sites are connected to the central hub and the central account is hacked, then it will lead to serious effects across several sites instead of just one.