Applications that provide first class APIs require more than simple authentication, they require api keys. API keys generated by your users allow their programmatic services to interact with your apis. These must be generated in a safe way and have different requirements than UI tokens.
In most cases with authentication, you’ll have JWTs to identify and authorize a user. These JWTs are coming from your authentication provider. Internally, you may also have api keys to authenticate your internal services from one to another. However having to authenticate users and service client differently causes issues:
Either you are generating service clients to provide your internal services access to one another, or generating API keys for your users to access your service’s APIs. We’ll use Service Client or API Key interchangeably as follows. But in general the Service Client is the service, and the API Key is the key the service client uses to identify itself. In the case you are providing a library or a CLI, the service client would be the developer or user, and they would pass the api key to the library or CLI at runtime.
The best way to do this is to provide service clients a way to create JWTs and more specifically be an identity provider. By converting service client api keys to public/private key format and signing a JWT, application APIs can verify tokens in a consistent manner. Also, since service clients are using JWTs they will contain identifying information. Additionally, the api key will never be exposed outside the service so security is increased.
This avoids all the issues that are generated by using the common flat api key as well as increases security for both the application API as well as the client caller.
Creating the key pair is simply done using available cryptography libraries in your preferred language. How there is more complexity added to make sure the configuration of your JWKs and identifying information is correctly consumed.
Getting this all correct can be challenging and leaves possible attack surfaces for vulnerabilities. To avoid these issues there is the service client API functionality available in the Authorization API.
The manual steps for doing the same thing are available in the UI:
And then add an access key:
So far we’ve solved the application side, but the service client still needs to connect. Pulling apart the access key and generating the client JWT is not simple, but the functionality is already provided in the authress-sdk.js (all available sdks).
We can wrap the service token provider functionality and deliver an application specific SDK that uses the builtin to handle all the complexity.