OAuth 2.0 implementation using IBM Cast Iron

OAuth 2.0 is the next evolution of the OAuth protocol and it is developed to be much simpler and easier to implement than it’s predecessor OAuth 1.0. This simplicity is achieved by removing cryptography from OAuth 2.0 and relying on SSL for the security.

While there is an ongoing debate over OAuth 2.0 security concerns,  OAuth 2.0 is quickly becoming popular and it is already supported by Facebook, Google and Microsoft and others.  Below I will outline the steps for implementing the OAuth 2.0 protocol for accessing protected Google API using IBM Cast Iron Studio.

It is worth to mention that as  the only signing algorithm supported by the Google OAuth 2.0 Authorization Server is RSA using SHA-256 hashing algorithm,and the only signature supported in Cast Iron is HMAC, the Service  Account flow (which is a OAuth 2.0 specification for 2-legged scenario) can not be implemented in Cast Iron, thus below only the  3-legged version will be addressed.

Below is the sequence diagram including all the steps in the OAuth 2.0 scenario from application registration to accessing the protected resources via Google API.

 

 

Once the resource owner ( user or administrator of Google domain) has registered an application with an intention to grant it access to set of Google API, the following attributes are generated:

• Client ID –  a unique string representing the registration information for the application, which is unique to the Authorization Server.
• Client Secret – an attribute used for client authentication in later steps

Using the specified attributes, application with an access to web can create and send the authorization code request to Google Authorization Server. This request triggers a message window in user’s Google account, stating that the described application requires access to the specified Google APIs. Once the user authorizes the application to access the APIs, Google Authorization Server creates a Authorization Grant Token and sends it back to the requesting application. This is a first step in OAuth 2.0 interaction, it is done only once at the beginning of the application registration. As Cast Iron Studio don’t have the ability to run as a SSL server (this option is only available in Cast Iron Live), the authorization step will be performed by the user.

Once Cast Iron receives the following attributes : client ID, client secret and the authorization code,  it can be fully automated to access protected Google APIs with OAuth 2.0. The steps below describe the process in details:

Using the obtained attributes: client ID, client secret and the authorization code, Cast Iron creates and sends a request to the Google Authorization Server for exchanging the authorization code with the access token and refresh token. Access token is a short-lived token enabling access to the protected API, whilst the refresh token is a long-lived token, used to renew the access token when it expires. Having both access and refresh tokens enables Cast Iron to access the protected resources, indefinitely, if  the application access hasn’t been revoked by the resource owner.