Cognito client secrets - API client

[fyliu]

Dependency

• 324

Overview

As discussed in #147, we need to implement app tokens in addition to user cognito tokens so we can restrict access to approved apps only. i.e. VRMS, website, CTJ.

• 147

Action Items

• [ ] research ways to add app tokens in django and DRF
• [ ] compare a few if there's many and write a decision record (DR) on why we should choose one
• [ ] create a work issue to implement the app token
• [ ] if #324 doesn't use client secret, update #242 to point to #323
• [ ] close this issue as done since there's a work issue for it and #328 also creates API clients with client secret enabled.

Resources/Instructions

• https://djangopackages.org and search for token
• Cognito's app client with client secret is an option

[fyliu]

I'm not sure if the role, stakeholder, feature labels are right.

I feel the "Infrastructure" feature might be wrong on this. Should this be under something like "Authentication"?

[ExperimentsInHonesty]

the labels are correct. Discussed during meeting with Fang and team.

[fyliu]

• Is this issue related to #242?

In OAuth2, there's the concept of app clients that are granted access to authenticate against cognito. The client_secret is one way to determine that a client is who it says it is. It's essentially a password.

But the client_secret is only for use by something that can protect secrets, such as backend servers. For frontends and mobile apps, they would use app clients that don't require a client_secret. They would need to verify their identities some other way.

This issue is interested in securing for frontends where the client_secret doesn't apply.

[fyliu]

Do we still want to have API keys?

API key is a little different than what we initially thought

• It's less secure than OAuth and is used more as an identifier than a security measure. It's mainly for applications such as logging actions by clients. Like how is CTJ using the API? What is it calling the most? etc.
• We can revoke the keys like we wanted
• To make use of the API key, a client would need to have a backend compnent to hide the key from the user. It'd be relatively easy to extract the key from the frontend code since it's loaded into the user's browser for execution.
  • Do all the people-depot clients have a backend component? CTJ, Website, VRMS? They would just need a little bit of code to add the API key to each request.

Cognito already supports this for login

• 242

• The above issue is exactly what the API key is: the client secret.

Do we want peopledepot API keys

• it would be for accessing the data API
• the data API already requires the cognito token that comes from logging in. So maybe it's enough that the cognito token uses API keys?
• The packages djangorestframework-api-key and django-oauth-toolkit can create API keys if we need it

[ExperimentsInHonesty]

We are going to use Cognito client secrets so that when a user logs into vrms or ctj (client systems), and the client system makes a request to authenticate that user and then show them data, we will know its coming from a client system

[fyliu]

We already have a work issue #242 to integrate with cognito using a client secret. It looks like that issue's dependency #241 is closed and we need to point to the new issue @ethanstrominger made #323, if the PR for it has the same problem of working only with client secret disabled.

• 242

• 241

• 323

• [ ] if #324 doesn't use client secret, update #242 to point to #323

• [ ] close this issue as done since there's a work issue for it and #328 also creates API clients with client secret enabled.

Putting this in the ice box until that PR is completed.