OAuth 2.0 Authentication

OAuth 2.0 covers different ways a client application can obtain authorization to access the resources stored on the resource server. The Ebase REST resource endpoints supports three OAuth 2.0 authentication types in accordance with RFC 6749:

2) Resource Owner Password Credentials Grant

3) Client Credentials Grant

OAuth 2.0 is an open authorization protocol which enables applications to access a user’s data. For example a game application can access a user’s data in the Facebook application, or a web application can access the data from a users Spotify account.

For example:

The user accesses the game web application. The game web application asks the user to login to the game via Facebook. The user logs into Facebook, and is sent back to the game. The game can now access the user’s data in Facebook. There is no username or password shared between the application requesting the user’s details and the application holding the user’s data. The user is taken to the website holding the user’s data (e.g Facebook) and the user must login and grant access for the game to access the user’s data. This authorization method is called Authorization Code Grant.

It is possible to grant access using a username and a password if the client holds the users username credentials. This works in a similar way to the Authorization Grant apart from the user does not to login to the server holding the user’s details, but the username and password are exchanged for access to the user’s details directly. This is called User Resource Owner Password Credentials Grant.

Authorization Code Grant

A client web application requesting access to resources in another web application is the most common way to grant access to a user’s personal data.

The process is as follows:

1) The user accesses the client web application. In this web application there is a button saying "Login via Facebook" (or some other system like Google or Spotify).

2) When the user clicks the login button, the user is redirected to the authenticating application (e.g. Facebook). The user then logs into the authenticating application, and is asked if she wants to grant access to her data in the authenticating application, to the client application. The user accepts.

3) The authenticating application redirects the user to a redirect URI, which the client app has provided to the authenticating application. Providing this redirect URI is normally done by registering the client application with the authenticating application. During this registration the owner of the client application registers the redirect URI. It is also during this registration that the authenticating application gives the client application a client id and a client password. To the URI is appended an authentication code. This code represents the authentication.

4) The user accesses the page located at the redirect URI in the client application. In the background the client application contacts the authenticating application and sends client id, client password and the authentication code received in the redirect request parameters. The authenticating application sends back an access token and refresh token.

5) Once the client application has obtained an access token, this access token can be sent to the Facebook, Google, Spotify etc. to access resources in these systems, related to the user who logged in.

6) Access tokens can expire and if applicable, a refresh token can be used to refresh the access token by sending the refresh token, client id and client secret to gain a new access token to Facebook, Google, Spotify etc...

Resource Owner Password Credentials Grant

It is possible to login to grant access to a user’s data using ‘username’ and ‘password’. This is exchanged for an access token to access an application holding a user’s personal data. This type of access is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.

The process flow is as follows:

1) The resource owner provides the client with its username and password.

2) The client requests an access token from the authorization server's token endpoint by including the credentials received from the resource owner. When making the request, the client authenticates with the authorization server.

3) The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.

4) Once the client application has obtained an access token, this access token can be sent to the server to access resources in these systems, related to the user who logged in.

5) Access tokens can expire and if applicable, a refresh token can be used to refresh the access token by sending the refresh token, client id and client secret to get a new access token.

Client Credentials Grant

The Client Credentials grant type is used when the client is requesting access to protected resources under its control (i.e. there is no third party). Client credentials grant exchanges the client credentials (client ID and client secret) and exchanges this for an access token. Client credentials grant does not return a refresh token.

The process flow is as follows:

1) Client Credentials (client ID and client secret) are sent to the authorization server. An access token is returned to the client.

2) Once the client application has obtained an access token, this access token can be sent to the server to access resources in these systems.

Configuring Ebase OAuth Authentication

OAuth authentication is configured through the Server Administration Application using the OAuth Configurations link on the main menu.

Introduction

Authorization Code Grant

Resource Owner Password Credentials Grant

Client Credentials Grant

Configuring Ebase OAuth Authentication