OAuth
2.0 Authentication
Resource Owner Password Credentials
Grant
Configuring OAuth Authentication
See also: REST Web Services overview, Server Administration Application Home Page, Server Admin OAuth Configuration, Using OAuth Security
OAuth 2.0 covers different ways a client
application can obtain authorization to access the resources stored on the resource
server. The Verj.io REST resource endpoints
supports three OAuth 2.0 authentication types
in accordance with RFC 6749:
2)
Resource
Owner Password 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.
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...
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.
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.
OAuth authentication is configured through the Server Administration Application using the OAuth Configurations link on the main menu.