-
Notifications
You must be signed in to change notification settings - Fork 1
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
Implement OAuth2 API authorization method #57
Comments
I'm curious if the SRE's have any suggestion for us here; otherwise, I was also thinking FastAPI's security docs had a path forward. |
@sciurus asked the question in our security operations Slack, and the feedback was:
I'm going to proceed with OAuth2, so we have some application-level protection of data, and we can evaluate if it is the right solution in the context of an RRA. |
I've worked my way through 4 of 5 steps in the FastAPI tutorial. It implements resource owners password credentials grant, where you pass a username and password to the We expect a small number of server-based clients, configured with a per-deployment access key that is applied using similar secret systems to database credentials. The matching OAuth2 workflow is a client credentials grant, where a client trades auth credentials for a short-lived (such as 1 hour) access token, without a refresh token. The workflow, in development and production, would be:
The cons of this process:
The pros of this process:
|
I've confirmed with @pmac that Basket will be able to use OAuth2 with client credentials to access CTMS, and that other flavors of OAuth2 are used to integrate with other services. |
Bonus points if I can use it with a library I'm already using: requests-oauthlib |
I've got in-progress code at main...jwhitlock:wip-oauth2. It adds the OAuth2 client credentials flow, and requires it for API endpoints. There's tests as well, and most tests fake authentication. The authentication uses hashing code that avoids giving away timing information, so the real authentication tests are noticeably slower. I want to re-organize the code into logical commits, clean up docstrings, and other cleanup. I also need to write and document
This is documented as Backend Application Flow using the BackendApplicationClient. However, the The client credentials grant type matches our use case, but it is not too late to switch to or add an OAuth2 grant type that is better supported by the tools. |
There's more I want to do with authentication, but let's track with new issues. |
Our current design is that API access requires authorization, and we expect a small number of production clients (Basket, a Mozilla Foundation client, and (maybe) a bulk CTMS importer). We also want to provide credentials to developers and integrators that are not used in production, and a way to easily generate credentials tied to a local development environment.
FastAPI has Security documentation that shows how to implement an OAuth2 workflow, and integrates this with the Swagger API docs. There are several OAuth2 clients, such as requests-oauthlib.
Are there other authorization frameworks we should consider?
Part of JIRA-OSS-302.
The text was updated successfully, but these errors were encountered: