In the product versions prior to API Manager In WSO2 API Manager versions prior to 1.9.0, the components were tightly coupled with the Key Manager and and token validation is was done by directly accessing DBsthe databases. But from the release version However, from WSO2 API Manager 1.9.0 onwards, you can plug different OAuth2 providers to the key validation in WSO2 API Manager. When we you call an API providing an access token, the execution flows through the handlers specified in the API. Among them, the API Authentication authentication handler extract extracts the token out from the header and call calls APIKeyValidationService to get the token validated. Upon validating the token gateway will receive an , the API Gateway receives APIKeyValidationInforDTO as the response. Using that , using which the rest of the operations will be are performed.
Before decoupling was done, the entire
...
key validation process was executed inside a single method named validateKey()
...
, which performed all the
...
operations by running
...
a single query.
...
After decoupling, that
...
single query was broken down into smaller
...
parts by introducing KeyValidationHandler which runs inside the validateKey() operation, providing a way to extend each step.
The KeyValidationHandler has four main operations as follows which executes in order.that are executed in the following order:
- validateToken - Validates the token. The existing implementation should work for most cases existing implementation would work.
- validateSubscription - SkippingSkips/Changing changes the domain validation.
- validateScopes - RelaxingRelaxes/Reducing reduces scope restrictions.
- GenerateConsumerToken - Create Creates different types of tokens.
The default implementation of the KeyValidationSercvice KeyValidationService was written in a way that, by only extending getTokenMetaData() method in KeyManagerInterface the user would be where you are able to complete the entire key validation flow only by extending the getTokenMetaData() method in KeyManagerInterface.
But However, there are situations where you need to customize the default Key Validation key validation flow according to different requirements. In In such situations, API Manager provide provides the facility to extend the KeyValidationHandler and the its methods of it.Following are some example
situationsA few examples are listed below.
| Requirement | Extension | ||
|---|---|---|---|
| Domain validation does not add any value and trivial steps such as these need to skip such trivial steps.be skipped | When creating a key via the API Store, the subscriber can specify which domains are allowed to make calls using a token granted against a particular consumer key.
| ||
| Need to avoid going into detail level in when validating scopes | Suppose you need not to go into the detail level if Consider a situation where a scope is assigned to a resource , but and you only need to verify if the token used to for access has at least one or more scopes defined for that API without going into much detail. This requirement can be achieved by extending the | ||
| 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 | A JSON Web Token (JWT) is used to pass 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 is required, then the generateConsumerToken() method can be extended to achieve that. |
...