Distribute APIs and have control over who is authorized to use it
Being in the software industry, there is always a need to exchange data between applications. Much of the data is available free nowadays, however, there are several pieces of data that need to land into the correct hands.
Data exchange is so easy that one has to develop an API and share the details with the consumer. Having said that, one should also safeguard the API by implementing checks on what the consumer is authorized to access.
In this post, we’ll try to implement an API authorization mechanism where only authenticated consumers can use the API and authorization will limit the usage of the API, as applicable
Below is the high-level design of our implementation. As seen, the Auth Server can be used to authenticate and authorize if any consumer can use the given API. The Auth Server will be capable such that the configuration for a particular consumer can be changed as and when required.
To design our Auth mechanism, below are the components that I chose to use. Viewers can use any technology or platform to it.
Note: The development is done only to carry out a proof of concept. It is advised to make necessary changes before using it in a production environment
- Express JS
- Java Web Tokens (JWT)
The API Management console is developed in Angular. This console will be used by the API Administrators to manage the API consumers. The Administrator can perform the following operations
- Add new clients (consumers)
- Edit the access of existing clients (consumers)
- Delete existing clients (consumers)
- Block/Unblock existing clients (consumers)
While adding a new client, the Administrator will have to enter the below mandatory details
- Client Company: This is the name of the company of the consumer (e.g. Acme, Appleseed, etc)
- Client Email: This is the email id of the contact person of the client company (e.g. firstname.lastname@example.org, email@example.com, etc)
- Provider Email: This is the email id of the business person of our company who is interacting with the client company (e.g. firstname.lastname@example.org, email@example.com, etc)
- Description: This has a summary of why the API access is granted to the client (e.g. Acme will access the Library API to manage the books in their library)
- Expiry Date: Every API access is valid up to a certain duration. This could be from a few days to a few years. API access will cease once the expiry date is reached
- Methods: This includes the list of methods that are allowed for use to a particular client. The methods can also be allowed based on the HTTP verbs (GET, PUT, POST, DELETE)
Once the client is created, the below options are available for use
- Token: This is a unique token (JWT) that will be given to the client for authorization purposes
- Block: Temporarily block the client and disable all access
- Delete: Delete the client forever
MongoDB has been used as persistent storage to save the API information. We have used a collection called “clients” who are considered as the consumers of the API. For now, the below document is being stored in the MongoDB collection
Express JS is used as a middleware (API) that interacts with the frontend Angular admin panel and the MongoDB for Persistent storage. Apart from these, a special method is developed namely validate.
The Auth server will expose the validate method to our API server. When the consumers (enrolled in the Admin Panel) consume any API (e.g. student, books, etc), they will have to pass in the token along with the request that was generated by the admin.
The API server will pick the token, method and the verb from the request and will pass on these to the validate method of the Auth server. Based on this information, the Auth server will decide if the request is valid (authenticated and authorized) or invalid.
Below are the requests and responses of the API server
Java Web Tokens (JWT)
JWT, in this post, is just used to generate the unique token given to each client. Based on the nature of JWT, some information related to the client can also be stored in the JWT.
- We will host the solution designed above on any server (I named it as the Auth server). This is the only piece that will be managed by us
- The API server is the one that has a plethora of APIs exposed to numerous clients. The API server will use the Auth server (validate method) to validate and verify the usage of the APIs. The admin of the API server will also use the Admin Panel to create and manage clients (consumers)
- The consumers will have to modify their requests to pass a token along. The API server will use this token (along with the method name and verb) to validate if the usage of the method is allowed by the client or not