In the product versions prior to API Manager 1.9.0, the components were tightly coupled with Key Manager and token validation is done by directly accessing DBs. But from the release version 1.9.0 onwards, you can plug different OAuth2 providers to the key validation in WSO2 API Manager. When we call an API providing an access token, the execution flows through the handlers specified in the API. Among them API Authentication handler extract the token out from the header and call APIKeyValidationService to get the token validated. Upon validating the token gateway will receive an APIKeyValidationInforDTO as the response. Using that the rest of the operations will be performed.
Before decoupling was done, the entire Key Validation process happened inside one single method named validateKey(). It performed all the operation running one single query. With the new framework, that big method broken down into smaller parts and provided a way to extend each step by introducing KeyValidationHandler which runs inside the validateKey() operation.
The KeyValidationHandler has four main operations as follows which executes in order.
- validateToken - for most cases existing implementation would work
- validateSubscription - Skipping/Changing domain validation
- validateScopes - Relaxing/Reducing scope restrictions
- GenerateConsumerToken - Create different types of tokens
The default implementation of the KeyValidationSercvice was written in a way that, by only extending getTokenMetaData() method in KeyManagerInterface the user would be able to complete the entire key validation flow.
But there are situations where you need to customize the default Key Validation flow according to different requirements. In such situations API Manager provide the facility to extend the KeyValidationHandler and the methods of it.
Following are some example situations.
| Requirement | Extension |
|---|---|
| Domain validation does not add any value and need to skip such trivial steps. | When creating a key via Store, subscriber can specify which domains are allowed to make calls using a token granted against a particular consumer key. Please refer Skipping Role Validation for Scopes for another example scenario. |
| Need to avoid going into detail level in validating scopes | Suppose you need not to go into the detail level if a scope is assigned to a resource, but only need to verify if the token used to access has at least one or more scopes defined for that API. This requirement can be achieved by extending validateScope() method. |
| Need to send a different type of token instead of JWT to pass details of API invocation to the backend. | As a method of passing details of an API invocation to the backend, a JSON Web Token (JWT) is used. If it is needed to send a different type of token, then generateConsumerToken() method can be extended to achieve that. |