In order for applications to consume Mapify services, customers are required to use an API key. This API key will allow customer applications to obtain a valid access token from Mapify Authorization service. The access token is a signed JWT token, digitally signed by Mapify, containing the claims to which the customer API key is associated. Customers will have access to Mapify’s administration console to manage their API keys and associated claims.
If you need to protect a certain service from unauthorized access, one has to ensure that the service requester has the appropriate claims to do so.
Some less optimal approaches require the service provider to check the caller’s identity through an authentication method, and sometimes another method needs to be used to check for the right permissions.
This process typically adds latency and additional risk, so early on developers resorted to solutions such as cookies and session management. This had the intention of avoiding multiple calls to authenticate and authorize the caller. Although it helped solve some issues, this approach also surfaced other issues such as scalability and dependencies.
An alternative approach is to demand that the caller of a service have certain claim(s) that allow it to access the service. These claims must be digitally signed by a trusted entity, which will be responsible to ensure the caller authentication and authorization.
This means that the service provider can simply check the claims sent by the caller’s request to determine access to its functionality. This is called claim-based authorization, and is how Mapify authorizes calls to its APIs.
Mapify requires the caller of its APIs to use a valid access token. Mapify access tokens are digitally signed JWT tokens which contain the necessary claims for the service invocation.
A full explanation about JWT tokens is out of the scope of this post, but they consist of JSON based tokens which, according to RFC 7519, are “a compact, URL-safe means of representing claims to be transferred between two parties“.
When invoked, Mapify services validate the access token and embedded claims to determine if the service caller has proper authorization.
The payload data of a Mapify access token may look like:
In order to generate a valid access token, Mapify requires that the caller first authenticates against its authentication service.
There are usually several options for authenticating a service caller, such as username and password credentials, digital certificates and API keys. This post focuses on API keys as credentials for server-to-server service invocation, which is one of the methods provided by Mapify.
Mapify customers can generate API keys through the Mapify administration console and assign them the necessary claims for desired Mapify APIs. Keeping the principle of least privilege in mind, API keys should only have the minimum required claims to the APIs that will indeed be used by the application using the API key.
The customer application can then invoke Mapify APIs using that access token. The access token will also include a refresh token that will be used when the access token expires.
Customer Defined APIs and Claims
One advantage of using Mapify Authorization is that customers can also use it to authorize their own APIs with their own claims.
Mapify customers can define their APIs and associated claims through the Mapify administration console. When they generate a new API key, they will be able to select not only from Mapify APIs and claims, but also from their own APIs and claims.