We have a use-case where our API needs to be integrated to a large number of different external systems that require different methods of authorization from us. Whilst some of these systems will be flexible enough to implement our chosen authorization approach, some are not and will say that we must support, for example, a bearer token.
Ideally we would like an authorizer that could look at the Authorization header for a key, then also try X-Api-Key (and potentially others in future I guess).
This doesn’t seem to work currently as the identitySource, despite supporting multiple header entries, cannot be not-null so that they can be used for cache keys. Therefore having an ‘OR’ approach to where an API key could doesn’t seem possible. This seems to be down to how AWS works under-the-hood, rather than a serverless thing.
I thought it would be worth seeing if anyone else has encountered this issue and found a solution?
The options I can think of so far are:
1). creating duplicate entry points for different auth methods (not appealing).
2). handling auth within the entry-points themselves (but we potentially lose the caching power of the responses, especially for invalid ones)
Thanks.