I now have a setup with 5 microservices. All these microservices are using the same JwtAuthProviderReader to be able to authenticate with the same JWT implementation - one of the microservices is the IdentityService.
This works perfectly but I now have an issue with ApiKeys. One of these microservices needs to support ApiKey as well. Of course when provided in the Authorization Header to that microservice, it is not recognized, as only the JwtAuthProviderReader is used in these services.
What I now basically did, is create a ApiKeyAuthProviderReader implementation; a property of this provider is an url to the Identity Service; in the Service I created a service to validate an ApiKey and return both ApiKey object and UserAuth object. The ApiKeyAuthProviderReader now implements IManageApiKeys and IUserAuthRepository. Most of the implementation are NotImplemented; I only implemented the ones that were called; I do some caching of the specific service in the IdentityService because basically it calls a lot of the same methods just providing the ApiKey and UserAuth objects.
My question is, did I miss something here, is there an already possibility in SS to use a kind of ‘external’ ApiKey provider? If not, what do you think of my solution?
The important part is that the new API Key AuthProvider needs to implement IAuthWithRequest so that PreAuthenticate() gets called on each request where it just needs to populate IRequest.Items[Keywords.Session] with the Authenticated UserSession, that’s essentially the objective of IAuthWithRequest Auth Providers which don’t need to rely on persisted Sessions or Cookies.
It’s not important to implement IManageApiKeys that’s just for existing Auth Repositories to be able to persist API Keys without needing to configure and initialize a new Repository just for API Keys.
It’s also pointless to have an “external” API Key Auth Provider as there is very little potential for reuse given the crux of the implementation is custom to retrieving and validating the API Key which is bespoke to each implementation.
Ok thanks for the pointer to IAuthWithRequest will investigate that part.
The other suggestion about generating new API Keys; in my case not necessary; all the users have there API key; it’s just another micro-service that I would like to support with the same api keys (as they can use jwt token for all these services).
For me it’s important to have that provider in place in my library as all my microservices can now benefit from that implementation. Thanks.