Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Custom runtime] add auth #3

Open
vincentsarago opened this issue Aug 13, 2021 · 5 comments
Open

[Custom runtime] add auth #3

vincentsarago opened this issue Aug 13, 2021 · 5 comments

Comments

@vincentsarago
Copy link
Member

use Cognito

https://github.com/tokusumi/fastapi-cloudauth

@zacharyDez
Copy link
Contributor

@vincentsarago how should we think about this with the deployments across multiple cloud providers? Should we just leave it to the end-user to configure authentication based on their context?

@vincentsarago
Copy link
Member Author

Should we just leave it to the end-user to configure authentication based on their context?

I guess 🤷‍♂️

It would be nice to have it implemented in our different demo services still

@zacharyDez
Copy link
Contributor

Yes, it came up during a call with some other external developers as being a key need that's unresolved for them...

@alukach
Copy link
Member

alukach commented Jun 23, 2023

A quick dump of thoughts on the topic of auth in reusable FastAPI systems:

On the VEDA STAC Ingestor, we have the maintainer provide the JWKS URL of whatever RS256-compliant auth provider they use (e.g. Cognito, Auth0) (1). This was done with the intention of the codebase being agnostic & flexible regarding auth setups. However, it comes at the cost of a lot of finer-grained controls. The STAC Ingestor basically asks "is this a valid token?" (2) and nothing more. It seems like fastapi-cloudauth is a bit more intelligent in terms of validating provider-dependent details in the auth scope (3, 4), which most likely more secure. Additionally, it adds tooling for custom verification of scopes/claims, which seems useful for anything but the most basic auth requirements.

On STAC-FastAPI, we added a convenience function to allow implementors to add custom dependencies (e.g. auth requirements) to endpoints on an existing (ie imported) FastAPI app (5). It feels a bit kludgey, but I'm not sure what a better solution would be for extending a FastAPI app with endpoints defined in files out of the control of the implementor.

One possible path forward would be to:

  • Allow user to optionally provide JWKS url for situations where basic auth is appropriate and the implementor is using eoAPI out of the box
  • Add & document/demonstrate a convenience method to make adding dependencies like those created via fastapi-cloudauth

@vincentsarago
Copy link
Member Author

eoAPI runtimes are demo applications. We should use them to show what we can do, so if we feel we should implement auth I'm totally 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants