Closed cjslep closed 3 years ago
ea8c804eac12566c38ab6bea6a06cd59a6d84a44 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:
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.id
to look up a payload of data. In this case, a credential_id
is associated with the user's cookie_id
session.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:
credential
entries80cff20b3f1464f8f22f9e10816e962e2ca56ae5 does the first bullet ("Verify the new model behaves in the database as expected")
c80fd1bf9c6423afbba8c8bb9f087d94f626e947 periodically cleans up expired credentials.
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.