OAuth 2.0 with WSO2 Identity Server

The OAuth2.0 authorization delegation protocol has gained wide attraction among the API communities for its ease of implementation compared to OAuth1.0a which involves signatures. It provides specific authorization flows (grant types in OAuth2.0 terms) for web applications, mobile and native applications and browser based clients.

The WSO2 Identity Server has the capability to function as an OAuth2.0 Authorization server. It also supports OAuth1.0a but in this post I will only be talking about OAuth2.0 support.

One of the popular products from WSO2 is the WSO2 API Manager. This product uses the same OAuth2.0 feature from the WSO2 Identity Server (enabled by the componentized architecture of Carbon platform powered by OSGi).

The OAuth2.0 core specification defines 4 authorization grant types for 4 different use cases.

1. Authorization Code grant type

The OAuth1.0a core specification talks about only one type of authorization flow mainly, which is the 3-legged flow. Authorization Code grant type is pretty much the evolution of OAuth1.0a which eliminates the need for signatures and relies solely on transport layer security such as SSL. This is a 3-legged flow and is the recommended and dominantly used flow for web applications. This flow involves two separate requests. First to the authorization endpoint and secondly to the token endpoint. In the authorization endpoint the resource owner authenticates himself and authorizes the client for a specific scope for a specific time period. The authorization server would respond with an authorization code to a callback URL specified by the client. In the second step the client would authenticate himself to the token endpoint and exchange the authorization code to an access token.

2. Implicit grant type

This  grant type has only one request. That is the request to the authorization endpoint. The resource owner as in the previous grant type would authenticate himself at the authorization endpoint. However the second step in the previous request does not take place here, which is the authentication of the client. Therefore the clients that use this grant type are known as public or anonymous clients because they don’t authenticate themselves. This grant type is defined in case of clients that live on the browser such as JavaScript clients. Here the clients credentials are kept in the browser, therefore can be seen by the resource owner or anyone who has got access to the browser session. Hence the the clients credentials are not confidential anymore and authentication does not make sense. However the client_id must be sent which can be used for throttling and monitoring (SLA) purposes. This grant type should be used with care, at the discretion of the Authorization server.

3. Resource Owner Password Credentials grant type

This grant type again has only one request. But this one talks to the token endpoint. Here the resource owner would need to provide his credentials to the client and the client would send those credentials and his own credentials to the token endpoint and authenticate both parties with their respective credentials and get back the access token. This type of grant is useful in scenarios where there is no browsers involved such as mobile apps or Desktop apps. Again this type of grant should be allowed at the discretion of the authorization server, suitably for reasons such as if the client is not able to take advantage of the browser and the clients are generally trusted parties and are certified to be trusted by the resource owners.

4. Client Credentials grant type

This grant is the most simplest grant type available. In this case the client directly sends an access token request to the token endpoint with his credentials. There is no resource owner credentials involved here. I.e. the resource owners do not authenticate themselves or authorize clients. This grant type is generally used in cases where the resources are public or else if the client is accessing resources owned by himself. So why do we need an authentication scheme at all if the resources are public? Or why do we need OAuth2.0 instead of HTTP Basic Auth if the client is accessing his own resources? Well, the answer for the first question is to impose SLAs and do monitoring, metering and billing. The answer for the second question is that the OAuth2.0 model has some inherent advantages not found with HTTP Basic Auth. Mainly the client credentials are exchanged for an access token which is used thereafter and the client’s credentials can be safely discarded until the access token expires. Therefore the frequency at which the client’s credential is required is reduced. Also the scope and lifetime of access given to the access token can be controlled unlike giving away the credentials which means if the credentials are compromised the masqueraders who obtain the credentials have complete authority over the user’s account until such time the legitimate user comes to know this and changes his credentials at the authorization server. But even that might be too late if the masquerader has already changed the password of that account. In such a case the consequences can be devastating.

Once an access token is obtained regardless of the grant type used resource access is the same from the client’s perspective. The client would send a resource request with the access token to the resource server. The request path would ideally be intercepted by an entity which will validate the access token with the authorization server and decide whether to let the request to continue or not. How the access token validation happens between the authorization server and resource server is implementation specific of the authorization server which OAuth2.0 does not talk about. The WSO2 Identity Server currently exposes a SOAP endpoint for this purpose. The WSO2 API Manager provides a SOAP endpoint as well as a Thrift endpoint for this purpose.

The OAuth2.0 specification has provisions for extensions at many places. The authorization grants and access tokens types are two main examples. One of the earliest grant type additions to the OAuth2.0 specification is the “SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants”. Although this is still at a draft stage we can see all the major players in the industry adopting this standard mostly with some level of customization. The WSO2 Identity Server also has support for this since its 4.1.0 release. I have talked about this support here. Another such extension grant type which is also at a draft stage is the “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants”. There are two major access token types that have been widely adopted in the industry; the “Bearer Token” (an IETF standard) and the “OAuth 2.0 Message Authentication Code (MAC) Tokens” (an IETF draft). The WSO2 Identity Server currently supports only the Bearer Token profile. For someone who wants an alternative for accessing resources with signatures, there is a customization available here.

Another complement to the OAuth2.0 specification is the “OAuth 2.0 Token Revocation” draft. The WSO2 Identity Server supports this draft as well from its 4.1.0 release, and you can read about it here.

The OAuth Bible is a comprehensive compilation of OAuth1.0a and 2.0 terminology and all their major flows.


How to use Facebook as OAuth 2.0 Authorization Server with WSO2 API Manager

The WSO2 API Manager comes bundled with an API Gateway, OAuth 2.0 Authorization Server and API Store and API Publisher jaggery apps. To increase the first time users’ experience all these components come bundled in a single distribution that is able run on a single JVM. However production recommendation is to deploy the four (or atleast three with the jaggery apps together) in a distributed setup.

One can have a requirement to use the WSO2 API Gateway with an external OAuth 2.0 Authorization server. I.e. to decouple the resource server from the authorization server in OAuth 2.0 terms. The OAuth 2.0 specification is silent on this. It does not talk about the interaction between the Resource server and the Authorization server. WSO2 API Manager has its proprietary implementation for this. However this requirement can be achieved. This is possible to do by configuring a new API handler in place of the default APIAuthenticationHandler. Each API that is published to the WSO2 API Gateway consists of a set of 5 default API handlers that do authorization, throttling, usage monitoring, etc. However it is important to note that the throttling and monitoring are based on the authorization keys of the client. If the authorization is decoupled from the API Gateway we won’t be able to use the APIMgtUsageHandler, APIThrottleHandler, etc.

Let’s say we need to use Facebook as the OAuth 2.0 Authorization server with the WSO2 API Gateway. The following diagrams illustrate the current OAuth 2.0 access token validation model and the proposed new model.

Access Token Validation with WSO2 Authorization Server

Access Token Validation with WSO2 Authorization Server

Access Token Validation with Facebook Authorization Server

Access Token Validation with Facebook Authorization Server