SECURITY INTERNAL . COM: OAuth 1.0a Three Legged Authorization using Playground Sample with WSO2 Identity Server 5.0

This post demonstrates the capabilities of WSO2 Identity Server 5.0.0 with Three Legged OAuth 1.0a [1] support. Here I use the Identity Server Service pack 1 installed setup. As the primary userstore I'm using a JDBC userstore which is a MySQL database.

Following diagram explains the Three Legged flow of OAuth 1.0a.

OAuth 1.0a (Three Legged) Flow, Image source : [2]

First step is to create the OAuth 1.0a Service Provider in Identity Server.

Then Edit the Service Provider configuration and click 'Configure' in 'OAuth/OpenID Connect Configuration' inside 'Inbound Authentication Configuration'.

When Registering the OAuth 1.0a application for the Service Provider, as the OAuth Version, 1.0a radio button should be selected. As the callback Url I specify following url where the hostname is 'localhost' and the port is '8080' as I'm going to host the playground sample application in tomcat which is running in port 8080.

Callback Uri : http://localhost:8080/playground1.0a/oauth/oauth_callback

Then you can see the generated OAuth Client Key and the OAuth Client Secret of the application. Note them down to be used later in the OAuth consumer application. Then Update the Service Provider configuration.

Next step is running the OAuth 1.0a consumer application. You can checkout the source of the playground sample application from [3] or if you just want the deployable web app, it can be downloaded form [4].

Here I have deploy the 'playground1.0a.war' web application in tomcat. The application can be accessed in the browser from following link.

http://localhost:8080/playground1.0a/index.jsp

You need to enter the OAuth Consumer Key, Consumer Secret and the Scope for getting the Request Token. Here I specify the Scope as 'openid'.

When the Identity Server receives the correct Consumer Key and the Consumer Secret, it generates the Request Token and Request Token Secret. When this happens, a record will be added to the IDN_OAUTH1A_REQUEST_TOKEN table in the JDBC userstore of the Identity Server. Since the request token is not yet authorized by a valid user, AUTHORIZED column value will be false and the AUTHZ_USER column value will be NULL which would contain the username of the user who authorized the request token.

The generated Request Token and the Request Token Secret will be sent to the consumer application.

Then the received OAuth 1.0a request token should be authorized. User can click on the 'Authorize Request Token' button and it will redirect to the Identity Server where the user has to enter credentials and allow delegation.

After the authorization, in IDN_OAUTH1A_REQUEST_TOKEN table the AUTHORIZED column value will be true and the AUTHZ_USER column will contain the username of the user who authorized the request token. It will also generate a random value and add to the OAUTH_VERIFIER column.

The consumer now receives the request token value and the OAuth verifier value where using the the consumer can get the Access Token.

When the Identity Server receives the same OAuth verifier from the consumer, it generates the OAuth access token and a record will be added to the IDN_OAUTH1A_ACCESS_TOKEN table.