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.

Sign up for GitHub

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

Jump to bottom

docs: authentication and authorization decision record added #108

Merged
merged 1 commit into from
Jul 16, 2021
Merged

docs: authentication and authorization decision record added #108

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions docs/decisions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,3 +116,19 @@ reverting deployments to a previous stable revision and rerouting traffic to a p
Deciding **which Serverless platform to use for the Website _and_ Content API**, facing the options of **Cloud Functions, App Engine, or Cloud Run**, we decided to **deploy to Cloud Run** for _both_ tasks. Cloud Run has more flexibility than Cloud Functions or App Engine, and additionally offers concurrency and traffic splitting, allowing for a more natural canary rollout pipeline.

* **Date:** 2021/06

## Decision: Require both user and application authorization

Some of the API methods deal with person-specific information, such as donations, which have a donor ID and a
contribution amount. Calls to those methods will require an Authorization header with value 'Bearer _jwt_' where
_jwt_ is an identity token from Google Identity Platform.

Many API methods don't deal with particularly sensitive content, so do not require user authentication. However,
we don't want random requests being made to the API, so we require the application use the API to be
"registered". That is, it must have an API key that the owner of the REST API issues. All API requests
will require an API key as a query parameter, as in `GET /campaigns?api_key=registered_key`. Our REST API
will get a list of valid values from an environment variable. The client application will get the
specific value from an environment variable.

Note that this means that some requests use two authentication methods, one for the application using the
API, and one for the user requesting a sensitive operation.