APIs that Consume APIs - JWT Bearer Grant Type

OAuth protocol has provision to design custom grant type in addition to the four grant types that are mentioned in the specification. SAML grant type is of the first grant types that came out as an extensions and many IdPs support this. Many IdPs allow to write plugins that enable other custom grant types, and among the most popular grant types are,

• Biometrics - Here the biometrics such as your fingerprint or retina scan is used obtain an access token. This is pretty useful for mobile apps.
• JWT - Here a service that has a JWT token may use it to obtain a access token to access another API

Here is a scenario for JWT grant type.

You are writing a service that allows employees to report time that they spend on customer work. Your service has received a JWT token so it can do authorizations.  One of the methods in the service is as below,

reportTimeForCustomer(String clientId, String ticketId, int durationInMinutes) {}

First of all, authorization checks happen based on the JWT and the next step is to validate clientId and ticketId before proceeding. There is a CustomerAPI and TicketAPI that can perform validations.

But both of these APIs are OAuth protected. How do you proceed? How would you obtain an access token to access this service. You have several options,

• You can take an application token
• You can take an access by presenting the JWT token as mentioned above

WSO2 APIM: Publishing APIs to External\Internal Parties

What if you want to have two API gateways - one for external facing APIs and the other for internal facing APIs? This can be achieved by two API manager deployments, but from WSO2 APIM 2.0.0 onwards this has become an inherent features supported by the product, so there is no need for two deployments. The solution is based on the multi-gateway feature. The multi-gateway feature allows one publisher to push APIs different gateway environments selectively.

At the time of publishing APIs, all available environments are listed in the publisher so that the API publisher can pick the correct environment. So the publisher will see all the environments available, in this case external and internal.

This allows publisher to push APIs to external or internal gateway selectively. So you can pick to expose an API on either external or internal gateway or on both of the gateways at the same time.

RBAC Store

In a real world scenario, internal users should be able to see only internal APIs and external users should be able to see only external APIs. This can be achieved via user roles. User roles can be defined for external and internal user, but sometimes it is not always scalable and can be troublesome as you have to assign users to specific roles.

Why two stores would be great?

What if we could deploy two stores, one for internal users and the other for external users. This will match the deployment expectation as well. The external store can be in DMZ (or accessible by outside world) and internal store can be internal network only.

This is added as a new feature to APIM road-map.

What about OAuth Keys and Throttling?

Underlying gateway/environments APIs are transparent to the OAuth keys. Irrespective of the API being exposed on a single or multiple gateways the number of cumulative API calls will be considered by the traffic manager when enforcing throttling.

WSO2 ESB - Serving Multiple Modern Apps from a Slow Legacy System

The story of serving thousands of requests sent by multiple modern applications in the downstream from a system that serves only 2 requests per second, basically how to get more bang from the existing buck!


Scenario - Vehicle Licensing Department of the Liliput Kingdom is going through digital transformation. As a step in this process they are going to introduce multiple applications to their manual processes. The apps can include,

• Mobile app running on vehicle owner's devices to check their vehicle licenses
• Customer service web app to check status of vehicle licences
• EverGreen - a third party organization that check vehicle emissions. It needs to get details of the licenses and vehicles.
• The vehicle license printing service needs to be automated

All the vehicle license information in a mainframe(MF) and this MF has one method for listing all the vehicle licenses. Calls for this method cannot exceed 2 per second. The goals of the architecture,

• Implement a solution by retrieving records from MF
• Expose REST services for the mobile, webapps and third parties
• Expose a SOAP API that the printing service is capable of calling
• Calls to down stream must not exceed 2 calls per second
• Calls to MF should be done over CICS

This is the solution proposed for Liliput VLD is based on WSO2 ESB. It helped VLD to remove point to point connections and perform mediation, transformation in minimal time.

High lights of the architecture,

• Create an intermediate database between the MF and new system - let's call it IDB
• Periodically retrieve delta from the MF and update the IDB
• Expose the data in IDB as a REST service
• Integrate data using the ESB to create composite interfaces
• Expose all APIs over APIM to be consumed by applications. This provides throttling, security and API analytics

The Vehicle Licensing Department of Liliput Kingdom achieved digital transformation much faster and less cost, due to this architecture.