[SSO] Use "authentications" table and support account linking
The SSO server has a (at least partial) capability to link multiple external provider accounts to the same user account. However, we currently bypass this capability and store the user id directly on the user record in "identity_url". We should:
- Remove the "identity_url" column and migrate it's contents to the 'authentications' table
- Enable users who are already logged in with one account to link additional accounts by logging in to other providers.
We're currently bypassing an existing abstraction in the SSO server that separates the concept of a user from the concept of a particular authentication provider. That's a problem because if we want to support multiple account providers (independently of account linking) we can't because we're bypassing the "authentications" table that is intended for that purpose. The way the SSO server was intended to be used, you identify users based on a user id allocated by the SSO server. Right now, we're passing through the OpenId "identity_url". But now we need to migrate to OAuth2. This is a blocker for supporting multiple authentication providers (at a single sso install).
The intended design of the SSO server (from the upstream developers) was you have a "users" table and each "user" has one or more "authentications". The "authentications" has the (provider, uid) tuple. But currently it ignores the "authentications" table and uses a hacked on "identity_url" on the "users" table, which ties it to OpenId 2.0, since the "users" table doesn't specify which provider is being used (but the "authentications" table does.)
#8 Updated by Tom Clegg almost 3 years ago
This seems to be mostly about catering to the sso-provider design. IMO our use of sso-provider is an awful hack that will die when we implement a sane authentication process, so I'm finding it hard to get excited about using its features.
I recommend we back off a bit from the implementation details and describe (from the user's perspective) with greater precision what "account linking" is expected to accomplish in various scenarios.
(My hope is that we can achieve that without making sso-provider any more entrenched.)