Storing Provider Auth + UserInfo Responses with Anvil user object

[christiansmith]

The User model currently stores third party provider IDs and access tokens as flat attributes in the schema. When a new user is provisioned, the profile available from the provider is mapped into the OIDC standard claims, and thereafter is not updated when authenticating. The original profile information is not stored, nor are additional parameters that may be available in the authorization response. This was quick and got the job done, but it's inadequate and disadvantageous going forward for a number of reasons.

@nrhope and I have been discussing improvements. Here's an summary of the proposed changes.

• Whenever a user is authenticated via a third party auth flow, the full authorization response and user profile from that provider should be stored in a user.providers hash.
• When a user is first provisioned, the mapping should continue as it does presently

Example:

{
  _id: "UUID",
  // ...
  // OIDC standard claims and
  // Anvil Connect specific properties
  // ...
  providers: {
    google: {
      provider: 'google',
      protocol: 'OAuth 2.0',
      auth: {
        access_token: '1ws2ed3rf4tg',
        token_type: 'bearer',
        refresh_token: '34f345g45gtf',
        id_token: 'eyfdsadfdsasdfdsa.blahblah.sig-na_ture'
        // etc
      },
      userInfo: {
        id: "asdfdsasfdsadf4312",
        // whatever raw userinfo we get back from the provider
      },
      authorized: TIMESTAMP,
      refreshed: TIMESTAMP
    },
    facebook: {
      provider: 'facebook',
      protocol: 'OAuth 2.0',
      auth: {
        access_token: '1ws2ed3rf4tg',
        token_type: 'bearer',
        refresh_token: '34f345g45gtf',
        id_token: 'eyfdsadfdsasdfdsa.blahblah.sig-na_ture'
        // etc
      },
      userInfo: {
        id: 431243234543,
        // whatever raw userinfo we get back from the provider
      },
      authorized: TIMESTAMP,
      refreshed: TIMESTAMP
    },
   // ...
  }
}

Questions:

• Should we ever update standard claims when a user reauthenticates or connects with an additional provider? Always? When additional information is available from the new provider? Never?
• Should storing profiles be a configurable option?

Making these improvements requires changing code in several places, including modinha-redis, which does not currently support indexing of nested properties.

[christiansmith]

This is more or less solved with df21464

cc: @nrhope