OAuth Authentication Framework

In a client-server model, authentication of the client to the server is an important issue.

There are several ways to accomplish authentication, one of which is regular authentication by username and password. This is basic authentication good for basic website protection. When security is more important basic authentication is not enough;

therefore, IETF (Internet Engineering Task Force) made an authentication framework called OAuth. The next paragraphs elaborate on different authentication methods and how OAuth works.

4.5.6.1 Principle concept

Within a classic client-server authentication, the client wants to use access protected resources on the server, which is done by authentication with the server. The authentication happens with the credentials of the resource owner. As the resource owner shares its own credentials with the third party application, some problems and limitations arise:

The resource credentials are stored in the third party applications for future use, often in clear-text.

The servers have to support password authentication, even if this causes security weakness because of the passwords.

The third-party application can have broad access to protected resources, without the resource being able to limit access to and duration of the resource.

Resource owners cannot limit access of one third party without limiting access of all third parties, which can then only be done by changing the third-party’s password.

Changing any third party application will result in a change of the end-user’s password and all the data that is protected by that password.

(Hardt, 2012)

OAuthwill deals with these issues by introducing an authentication layer, and making a separation between the client role and the resource. The client requests access to the resources through a resource server that is controlled by the resource owner.

The previous attempt to access resources used the resource owner’s credentials, now the client gets an access token, containing the scope, lifetime and other access attributes.

The access tokens are gained from an authentication server.

In OAuth there are four important roles:

Resource owner: The entity that is able to give access to the protected resources.

Resource server: The server that owns the protected resources and is capable of accepting and responding to the requests for accessing the protected resources through access tokens.

Client: The application that makes requests for accessing the protected resources, and this with authorization of the resource owner.

Authorization server: The server that gives the access tokens to the client after a successful authentication of the resource owner and obtaining authorization.

(Hardt, 2012)

4.5.6.2 Handshake

Figure 32 OAuth2 authentication flow (IdentityManagement, 2012)

Figure 32 shows how the authentication works for OAuth2 between the four roles.

a) The client requests authentication from the resource owner. The client can get its authorization request directly from the resource owner or preferably indirectly via the authorization server.

b) The client receives an authorization grant. This is a credential that stands for the resource owner’s authorization, and represents one of the four grant types or an existing grant type. The type of grant type is depending on the method used by the client.

c) The client asks for an access token by presenting the authorization grant and shows this to the authorization server.

d) The authorization server checks if the client is authorized to access recourses and validates the authorization grant; if valid the access token is given.

e) The client presents the access token to the resource server and asks for access to the protected resources.

f) The resource server checks the validation of the access token and if its valid the server gives the client access to the resources.

(Hardt, 2012)

4.5.6.3 Authorization Grant

There are several authorization grant methods. The different methods all have the same purpose: the client needs to have authorization to access the resources and this is done by obtaining an access token.

4.5.6.3.1 Authorization Code

The authorization code is received from the authorization server that acts as an intermediate layer between client and resource owner. This means, that the authorization is not requested directly from the resource owner, instead the client is redirected to an authorization server that returns the authorization code to the client.

The client never gets the resource owner’s credentials, since this information is never shared. Instead the resource owner is authenticated with the authorization server and the authorization code is send through the authorization server to the client. (Hardt, 2012)

The authorization code grant type is used to access and refresh the tokens. The client must be able to communicate with the resource owner’s user-agent, because this grant is redirection-based flow. Moreover, the client must be able to receive incoming request that are redirected from the authorization server. (Gazit, Authorization Code Grant, 2012)

Figure 33 shows the flow of the authorization code grant type. These are the following steps:

a) The flow is initialized by the client through the user-agent of the resource owner to the authorization endpoint. The client request includes the client identifier, requested scope, local state and redirection URI that is needed for the authorization server to send if the access is granted or denied.

b) The resource owner is authenticated by the authorization server via the user-agent. The authorization server establishes the connection if the resource owner grants or denies the client’s access request.

c) If the access is granted, the authentication server will redirect the user-agent to the redirection URI that is given by the client. The redirection URI contains the authorization code and previous state of the client.

d) The client requests for an access token from the authorization server, this is done by including the authorization code that has been send in the previous step. The redirection URI that is used for getting the authorization code is verified by the client.

e) In the last step the authorization server authenticates the client by checking the authorization code. If this is all valid the authorization server will respond with an access token and optional a request token.

(Gazit, 2012)

Figure 33 Authorization Code grant (Gazit, 2012)

4.5.6.3.2 Implicit grant

The implicit grant flow is a reduced version of authorization code flow. It is used for clients that use a browser with a scripting language like JavaScript. With implicit grant the client does not use an authorization code, it gets its access token directly. The grant type is implicit because there is no use of an authorization code. The authorization server does not authenticate the client by issuing the access token. The client can be identified by verifying the redirection URI that is used to deliver the access token to the client. (Hardt, 2012)

Figure 34 shows the flow of an implicit grant type; the following steps are taken:

a) The flow is initialized by the client through the user-agent of the resource owner to the authorization endpoint. The client request includes the client identifier, requested scope, local state and redirection URI that is needed for the authorization server to send if the access is granted or denied.

Figure 34 Implicit grant flow (hansamann, 2012)

b) The resource owner is authenticated by the authorization server and this via the user-agent. The authorization server establishes the connection if the resource owner grants or denies the client’s access request.

c) If the resource owner grants access for the client then the authorization server redirects the user-agent back to the client redirection URI. The access token is included in the redirection URI.

d) The user-agent makes a request to the web-hosted client resource by following the redirection instructions. The fragment information is retrieved locally by the user-agent.

e) The web-hosted client resource returns a webpage that is able to access the redirection URI that includes the fragment. This fragment is gained from the previous step, which also includes the access token.

f) The script is executed by the user-agent, and will extract the access token from the resource.

g) The access token is then passed to the client.

(Gazit, Implicit Grant, 2012)

4.5.6.3.3 Resource Owner Password Credentials Grant

The use of the resource owner password credentials (username and password) makes it possible to obtain an access token directly. This authorization type should only be used when the client and the resource owner have a trustful relation. This grant type makes a straight connection between the client and the resource owner to access the credentials of the resource owner. The resource credentials will only be exchanged for an access token. (Hardt, 2012)

Figure 35 Resource owner password credentials flow (hansamann, OAuth2: The Resource Owner Password Flow, 2012)

Figure 35 shows the Resource owner password credentials flow, which consists of the following steps:

a) The resource owner provides the client with a form to fill in his username and password.

b) The client requests for an access token from the authorization server. In this request the client includes his credentials received from the resource owner. The client authenticates itself with the authorization server when it is making a request.

c) The client will be authenticated by the authorization server and the server checks the validation of the resource owner’s credentials. If the credentials are valid then an access token is given. (Gazit, Resource Owner Password Credentials Grant, 2012)

4.5.6.3.4 Client Credentials Grant

The client credentials can be used when the authorization scope is limited to the protected resources that are under control of the client, or when the resources are under control of a previously arranged resource owner. This grant type is used when the client acts as the client itself and as the resource owner. The client can ask for the access token using only the client credentials. (Hardt, 2012)

Figure 36 shows the flow of a client credential grant type; the following steps are taken:

a) The client authenticates with the authorization server and requests for an access token.

b) The authorization server checks if the client can be authenticated and if this is possible the access token will be passed to the client.

(Gazit, Client Credentials Grant, 2012)

Figure 36 Client Credentials flow (hansamann, OAuth: the Client Credentials Flow, 2012)

4.5.6.3.5 Conclusion

The grant type that is most suitable for this project is authorization code, because here the client interacts with an authorization server through a user-agent. This is a secure way to make sure that the client is legit to access the resource. Another possible grant type is the Resource Owner Password Credentials, since there is a trustful relationship between client and server. In this project OAuth2 is not used, as it would take a database change, which is not possible.