I’m currently migrating some WebAPI endpoints over to ServiceStack. These endpoints have a couple of different authentication mechanisms.
First one is custom api key implementation and second one is origination IP based. I figure I have two options.
First create a separate auth provider for each one, implementing IAuthWithRequest. Only problem I see with this is that these extra providers will get called on every type request - when in fact they are only needed for their respective endpoints.
This lead me to think of an alternative which is around implementing a request filter attribute with in process authenticate request?
Note: an IAuthWithRequest provider is only called conditionally when it’s needed, either in the [Authenticate] Request Filter Attribute before validating if a user is authenticated, or the first time the Users Session is retrieved for that request, i.e. with req.GetSession(). So there’s no overhead if an Auth request is sent to a public (i.e. non authenticated) Service.
Hard to say, I think an IP whitelist makes sense as a Request Filter, but an API Key implementation would make more sense as an Auth Provider which is effectively an alternative for authenticating. If it helps most of our API Key Auth Provider implementation is encapsulated in ApiKeyAuthProvider.cs.
All my services are secured by credentials - but these two are different. An option could be to modify the authenticate attribute to allow me to explicitly specify list of auth providers to use (currently you can only specify one). Do you think this is a reasonable approach?
I don’t think modifying the built-in [Authenticate] is a good idea if that’s what you mean, as you’ll then need to forever maintain your own impl.
I’d also personally avoid having to authenticate with 2 Auth Providers which sounds unnecessarily complex for a single request to need to validate with multiple auth providers. If it’s possible, I’d encapsulate all auth logic in a single Auth Provider which does what you need.