Background
There is an authorization service implementing a token endpoint to issue API access tokens to registered clients with valid client credentials. The implementation is inspired by OAuth 2.0 Client Credentials Grant in spirit but not in letter. The areas of difference is listed below:
-
Input Content-Type is application/json whereas the spec requires application/x-www-form-urlencoded
-
Names of request parameters are (ClientId, ClientSecret) whereas the spec requires (client_id, client_secret)
-
Missing required input parameters are (grant_type)
-
Names of response attributes are (token, expiresIn) whereas the spec requires (access_token, expires_in)
-
Missing required output parameters (token_type)
-
Missing required output headers (pragma, cache-control) for responses containing tokens
Any client - be it first party or third party - which implements standard OAuth 2.0 Client Credentals Grant type for getting tokens will NOT be able to consume the token endpoint in an OOTB fashion and will require some form of custom logic to consume the endpoint.
Note: This is not an imaginary problem but something encountered by the author at a certain organization.
Problem Statement
-
Provide OAuth 2.0 Client Credentials Grant type compliant token endpoint for APIs.
-
The endpoint must be an addition and not modification of existing endpoint so that the existing consumers are not broken.
-
The solution must be simple and quick to implement (days and not weeks)
Options
-
Option 1: Authorization service team implements a new compliant endpoint in code.
-
Option 2: Implement an API gateway proxy for doing the conversion for compliance.
This proxy does the required translation to provide an OAuth 2.0 Client Credetials Grant type compliant endpoint for API consumers. Any new API consumers which require a compliant endpoint for tokens make use of this new endpoint exposed on API gateway.
Recommendation
Chose Option 2 because it achieves the goal of OAuth 2.0 Client Credentials Grant type compliant token endpoint without requiring any change to API consumers, existing token endpoint and its existing consumers.
The proxy exposes a single endpoint for tokens and is stateless.
The only effort required is to create an APIGW proxy configuration and deploy it using the exiting CICD pipeline.
Note: The organization had an APIGW deployed and along with a well-defined CICD mechanism.
Positive Consequences
-
Minimal development time
-
Uses existing and proven infrastructure (APIM)
-
Uses existing CICD pipeline (APIM)
Negative Consequences
- Needs learning of API gateway proxy development skills and maintenance and extension of the configuration as needed.
Architecture
Fig. 1 High-level architecture
Fig.2 Sequence diagram
In Conclusion
API gateways are commonly used for security, traffic management, and header/url/payload transformations. One usecase where the API gateway can be leveraged is to expose endpoints compliant with standards without affecting existing endpoints which are non-compliant but in active use. The standards could be industry standards like OAuth 2.0 or (internal) company standards for API design.