An idea how to support auth in stapi-fastapi

[jkeifer]

I have been thinking about this topic and wanted to throw out a proposal. I think if we can get general alignment here the product would be some sort of documentation outlining how to set this up rather than any code changes.

The (perhaps obvious) problem with auth is that it is always different: different auth mechanisms, different permissions models, different types of users, etc. How then can stapi-fastapi accommodate auth when there's such a diversity of needs and implementations?

The answer I've been arriving at as I ponder this question is simple: stapi-fastapi doesn't. With where stapi-fastapi fits an a STAPI server implementation I think it is entirely possible that we have no auth-related code in stapi-fastapi and yet do not impose any practical limits on what auth can or cannot be supported.

Perhaps if I can describe an example architecture this idea will make more sense. Imagine we have a stapi-fastapi implementation deployed behind a reverse proxy. This could be apache, nginx, AWS API Gateway...you name it.

Any of these proxies support handling authentication (in particular thinking about something like OIDC). They can ensure users are authenticated and that requests have an oauth2 bearer token in their headers before proxying the request to the stapi-fastapi server.

As stapi-fastapi provides routers that get included in a FastAPI app, not the app itself, it is trivial for users to attach any required middleware to their app to ensure a valid bearer token is included in each received request (throwing a 401 if not) and has been parsed into a usable format attached to the request state. The user-created backend methods that end up being called by stapi-fastapi routes get the request as an argument. These methods--which are implemented by the user according to their requirements--can check for the required grants in the bearer token as required to do what has been requested, and can throw a 403 if the user is not authorized to do what has been requested.

With this structure stapi-fastapi doesn't have to care at all about auth. It's entirely up to the implementation to do that as required, and stapi-fastapi doesn't get in the way of the implementation doing so.

Thoughts? Gaps? Problems? Concerns?

[jkeifer]

I suppose one thing we did a little while back with the whole product router restructuring was to make it so users did not have to implement the method returning products on the root router. This is maybe one gap: how do we control the exposure of products depending on the grants given to the requesting user?

It seems like we might need to allow overriding that default behavior so they can control which products get exposed per the requestor. Same within the product router regarding access to the product endpoints that do not require backend functionality: maybe we need an auth hook function in the product that, if defined, is run prior to any endpoint without a backend function. Perhaps this is also the function that controls whether a product is included in the result set in the root router, so we only have to implement the one function to control product access across the board?

[gadomski]

@jkeifer check out https://github.com/developmentseed/stac-auth-proxy ... I think we could re-use it here.

[doublebyte1]

@jkeifer @gadomski here is another example of auth handled in a separate layer, on top of the API. This was used for protecting pygeoapi, but I think it could also be reused in this use case:

https://github.com/cartologic/pygeoapi-auth-deployment