OAuth 2.0 framework

There are two main concepts which goes with Oauth 2.0 framework.

1. Authentication

Authentication is about validating your credentials like User Name/User ID and password to verify your identity. The system determines whether you are what you say you are using your credentials. In public and private networks, the system authenticates the user identity via login passwords. Authentication is usually done by a username and password, and sometimes in conjunction with factors of authentication, which refers to the various ways to be authenticated.

2. Authorization

Authorization, on the other hand, occurs after your identity is successfully authenticated by the system, which ultimately gives you full permission to access the resources such as information, files, databases, funds, locations, almost anything. In simple terms, authorization determines your ability to access the system and up to what extent. Once your identity is verified by the system after successful authentication, you are then authorized to access the resources of the system.

To handle these two concept, we can use OPENID, Ouath 2 . 0 Framework and SAML. Here is comparison between these technologies.

First of all, Let’s look at what is Oauth 2.0?

OAuth 2 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service, such as Facebook, GitHub, and DigitalOcean. 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.

OAuth 2.0 Framework provides,

• Federated Identity — Allowing users to log in to an application with another account.
• Delegated Authority — Allowing another service to access resources on another service on behalf of the user.

This informational guide is geared towards application developers, and provides an overview of OAuth 2 roles, authorization grant types, use cases, and flows.

Let’s get started with OAuth Roles!

Roles

• Resource Owner : This entity can grant access to a protected resource or a service. The resource owner is a person (like an end user), an application that owns the service, or a security policy. The resource owner is depicted in the illustration that follows as a person, which is probably the most common situation.
• Resource Server : This is the server hosting the protected resource or service. The resource server can accept and respond to protected resource requests. In Oracle Cloud, a resource server represents an application hosting cloud services.
• Client Application : This is an application or service that can make protected resource requests on behalf of the resource owner. The client application is the application requesting access to resources stored on the resource server. The client application also obtains authorization from the resource owner. The client application is also referred to as OAuth client. In Oracle Cloud, an OAuth client represents an application making a REST API call. Examples of OAuth clients are the Oracle Mobile Cloud Service and the Oracle Java Cloud Service-SaaS Extension.
• Authorization Server : This server supplies access tokens to the client after successfully authenticating the resource owner and obtaining authorization. In Oracle Cloud, the OAuth service takes on this responsibility.

Next there are two type of tokens :

Tokens

Tokens are random strings generated by the authorization server and are issued when the client requests them.

There are 2 types of token:

• Access Token: this is the most important because it allows the user data from being accessed by a third-party application. This token is sent by the client as a parameter or as a header in the request to the resource server. It has a limited lifetime, which is defined by the authorization server. It must be kept confidential as soon as possible but we will see that this is not always possible, especially when the client is a web browser that sends requests to the resource server via Javascript.
• Refresh Token: this token is issued with the access token but unlike the latter, it is not sent in each request from the client to the resource server. It merely serves to be sent to the authorization server for renewing the access token when it has expired. For security reasons, it is not always possible to obtain this token. We will see later in what circumstances.

HTTPS

OAuth2 requires the use of HTTPS for communication between the client and the authorization server because of sensitive data passing between the two (tokens and possibly resource owner credentials). In fact you are not forced to do so if you implement your own authorization server but you must know that you are opening a big security hole by doing this.

Authorization grant types

There are five types of grants specified in the OAuth 2.0 specification. Namely,

• Authorization grant
• Implicit grant
• Resource owner credentials grant
• Client credentials grant
• Refresh token grant

Next most thing is End Points :

• Redirection Endpoint — This is provided by the Client Application to the service provider. The service provider will send the access tokens etc to this endpoint.
• Authorization Endpoint — This is the endpoint the Client Application should use to initiate the Authorization process.
• Token Endpoint — This is the endpoint the Client Application should use to initiate Token flow.

Authorization Code Grant

When it should be used?

It should be used as soon as the client is a web server. It allows you to obtain a long-lived access token since it can be renewed with a refresh token (if the authorization server enables it).

Example:

• Resource Owner: you
• Resource Server: a Google server
• Client: any website
• Authorization Server: a Google server

Scenario:

1. A website wants to obtain information about your Google profile.
2. You are redirected by the client (the website) to the authorization server (Google).
3. If you authorize access, the authorization server sends an authorization code to the client (the website) in the callback response.
4. Then, this code is exchanged against an access token between the client and the authorization server.
5. The website is now able to use this access token to query the resource server (Google again) and retrieve your profile data.

You never see the access token, it will be stored by the website (in session for example). Google also sends other information with the access token, such as the token lifetime and eventually a refresh token.

This is the ideal scenario and the safer one because the access token is not passed on the client side (web browser in our example).

Sequence diagram:

Implicit Grant

When it should be used?

It is typically used when the client is running in a browser using a scripting language such as Javascript. This grant type does not allow the issuance of a refresh token.

Example:

• Resource Owner: you
• Resource Server: a Facebook server
• Client: a website using AngularJS for example
• Authorization Server: a Facebook server

Scenario:

1. The client (AngularJS) wants to obtain information about your Facebook profile.
2. You are redirected by the browser to the authorization server (Facebook).
3. If you authorize access, the authorization server redirects you to the website with the access token in the URI fragment (not sent to the web server). Example of callback: http://example.com/oauthcallback#access_token=MzJmNDc3M2VjMmQzN.
4. This access token can now be retrieved and used by the client (AngularJS) to query the resource server (Facebook). Example of query: https://graph.facebook.com/me?access_token=MzJmNDc3M2VjMmQzN.

Maybe you wonder how the client can make a call to the Facebook API with Javascript without being blocked because of the Same Origin Policy? Well, this cross-domain request is possible because Facebook authorizes it thanks to a header called Access-Control-Allow-Origin present in the response.

More information about Cross-Origin Resource Sharing (CORS): https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS#The_HTTP_response_headers.

Attention! This type of authorization should only be used if no other type of authorization is available. Indeed, it is the least secure because the access token is exposed (and therefore vulnerable) on the client side.

Sequence diagram:

Resource Owner Password Credentials Grant

When it should be used?

With this type of authorization, the credentials (and thus the password) are sent to the client and then to the authorization server. It is therefore imperative that there is absolute trust between these two entities. It is mainly used when the client has been developed by the same authority as the authorization server. For example, we could imagine a website named example.com seeking access to protected resources of its own subdomain api.example.com. The user would not be surprised to type his login/password on the site example.com since his account was created on it.

Example:

• Resource Owner: you having an account on acme.com website of the Acme company
• Resource Server: Acme company exposing its API at api.acme.com
• Client: acme.com website from Acme company
• Authorization Server: an Acme server

Scenario:

1. Acme company, doing things well, thought to make available a RESTful API to third-party applications.
2. This company thinks it would be convenient to use its own API to avoid reinventing the wheel.
3. Company needs an access token to call the methods of its own API.
4. For this, company asks you to enter your login credentials via a standard HTML form as you normally would.
5. The server-side application (website acme.com) will exchange your credentials against an access token from the authorization server (if your credentials are valid, of course).
6. This application can now use the access token to query its own resource server (api.acme.com).

Sequence diagram:

Client Credentials Grant

When it should be used?

This type of authorization is used when the client is himself the resource owner. There is no authorization to obtain from the end-user.

Example:

• Resource Owner: any website
• Resource Server: Google Cloud Storage
• Client: the resource owner
• Authorization Server: a Google server

Scenario:

1. A website stores its files of any kind on Google Cloud Storage.
2. The website must go through the Google API to retrieve or modify files and must authenticate with the authorization server.
3. Once authenticated, the website obtains an access token that can now be used for querying the resource server (Google Cloud Storage).

Here, the end-user does not have to give its authorization for accessing the resource server.

Sequence diagram:

Access token usage

The access token can be sent in several ways to the resource server.

Request parameter (GET or POST)

Example using GET: https://api.example.com/profile?access_token=MzJmNDc3M2VjMmQzN

This is not ideal because the token can be found in the access logs of the web server.

Authorization header

GET /profile HTTP/1.1
Host: api.example.com
Authorization: Bearer MzJmNDc3M2VjMmQzN

It is elegant but all resource servers do not allow this.

Security

OAuth2 is sometimes criticized for its permeability, but it is often due to bad implementations of the protocol. There are big mistakes to avoid when using it, here are some examples.

Vulnerability in Authorization Code Grant

There is a vulnerability in this flow that allows an attacker to steal a user’s account under certain conditions. This hole is often encountered and also in many known websites (such as Pinterest, SoundCloud, Digg, …) that have not properly implemented the flow.

Example:

• Your victim has a valid account on a website called A.
• The A website allows a user to login or register with Facebook and is previously registered as a client in Facebook OAuth2 authorization server.
• You click on the Facebook Connect button of website A but do not follow the redirection thanks to Firefox NoRedirect addon or by using Burp for example (callback looks like this: http://site-internet-a.com/facebook/login?code=OGI2NmY2NjYxN2Y4YzE3).
• You get the url (containing the authorization code) to which you would be redirected (visible in Firebug).
• Now you have to force your victim to visit this url via a hidden iframe on a website or an image in an email for example.
• If the victim is logged in website A, jackpot! Now you have access to the victim’s account in website A with your Facebook account. You just have to click on the Facebook Connect button and you will be connected with the victim’s account.

Hope, now you have good understanding about OAuth 2.0 framework.