OAuth first-party proxy

[cjslep]

As mentioned in #36, an internal proxy is needed to manage the first party login page of applications using apcore. This means the underlying auth used is uniform for third and first parties, we can just provide a slightly different user experience for the first-party.

[cjslep]

ea8c804 has an internal proxy when a user goes through a typical login/logout endpoint flow, so that an OAuth credential is generated in the process. The way it is structured is as follows:

• The user's browser has a cookie as usual, containing a cookie_id (which, as usual, should be protected from XSS). The cookie_id itself is not PII but it is sensitive.
• The server session uses the cookie id to look up a payload of data. In this case, a credential_id is associated with the user's cookie_id session.
• The credential_id has an entry in the new first_party_creds table that associates the credential_id with a user_id and an oauth_token_id.

The expirations for that OAuth token are able to be checked like any other OAuth token. Furthermore, there is a middleware function that checks if a user that is browsing has a cookie_id, and if it has a credential_id, if it needs to be refreshed (close to expiry), and if so, refreshes it, without interfering with the user's experience.

Further work to be done:

• Verify the new model behaves in the database as expected
• Create a periodic job that cleans out stale credential entries

[cjslep]

80cff20 does the first bullet ("Verify the new model behaves in the database as expected")

[cjslep]

c80fd1b periodically cleans up expired credentials.