Basic solution enabling external users to authenticate against our public APIs in a way we can track

[mxk0]

Summary

Today, API auth uses static keys. We haven't made these keys available to external users, and there is no process for ensuring we can link an API request with a specific user.

In support of quadly deliverables like #2200 and our general ability to deliver public API features, we need process and functionality that allows external users to hit the API in a way that allows us to identify where an API request is coming from.

We should deliver this as the simplest solution that meets our acceptance criteria. More robust features e.g. self-serve public API key generation can come later.

Acceptance criteria

• [ ] API users can authenticate with our public APIs
• [ ] Simpler staff can associate an API request with a specific API user

[mxk0]

@btabaska @mdragon @chouinar does this capture everything we need for basic public API keys? Also, this is my first GitHub issue on this project (🎉), let me know if I'm missing any team conventions or expected details.

[btabaska]

Looks good on my end. Bookmarking this to follow this thread of work. Thanks so much!

[chouinar]

Do we want this task to be to implement something more than what we have (even if not a full approach like API Gateway), or just to add a small bit of formality to what we have?

For context, what we have right now is a set of keys defined as a secret env var that gets loaded when the API initializes. So, for example, if we configured it to be abc123,mno456,xyz789, each of these keys (comma-separated) would be valid, and adding new keys just requires adding to this key. The API "tracks" the user by logging which key it was called with by labeling each of them as auth_user_{n} where n is just the user in the array. So, if you use key mno456, it would log the user as auth_token_1.

Technically if we knew that key X was only used by user Y, then we'd know who is calling us, but this approach is obviously not a reasonable long term approach, but might be fine as long as we stay small with ~5 users.

[mdragon]

@chouinar I think for the October time period (so our work the first few Sprints) we can do this with a spreadsheet of the keys and who we shared them to. We can pre-build 10-15 keys and bake them into the environments and then we can assign them as each of us gives them out, kinda thing. I think that should hold us until we get to the point where we can implement this using API Gateway or otherwise and retire this temporary stop gap.

[chouinar]

@mdragon - I've updated prod to have 20 keys, and updated dev and staging to each have 5.

Will test this after the next prod deploy when the env var gets re-loaded.