Closed skluck closed 6 years ago
We can use Lusitanian/PHPoAuthLib which supports a ton of oauth providers including GitHub. It's widely used, though the way it builds services isn't super great.
For supporting multiple providers - we need to separate the concepts of User
and Identity
.
So we create a new identity table and FK it to the Users table. Users
should have only properties that are independent of provider.
id
(PK, GUID)email
(we will treat this as unique)username
(Maybe??? Not sure if we need this)name
(Users can update this at will, but we can import from provider if available)id
(PK, GUID)provider_type
(github
, ldap
, internal
, etc)provider_id
(unique id provided by provider)parameters
(Not sure about this one - info provided by the provider?)token_parameters
(Not sure about this one - should be encrypted. things like tokens, refresh tokens)We'll need a strategy for de-duping. What happens if a user signs in with github
, then signs in later with google
(for example)? Are they different users? How do we link those identities together? We can't necessarily trust that using the same email at every provider means they control that 3rd party account.
Potential vulnerability:
userA@example.com
from github
random oauth provider
with userA@example.com
and doesn't verify the email, or the provider doesn't enforce verification.random oauth provider
, which sees the email and grants UserB access to UserA's Hal account.One solution I've seen is to only auto-create a user on first login. Users can then manually link other provider auths from their user page. This way, a user has to be signed in before granting access to any further identities after the first one.
There's a really good answer on stack overflow about this https://stackoverflow.com/questions/6666267/architecture-for-merging-multiple-user-accounts-together
Currently only LDAP is supported for auth.
We should also support internal users (for admin purposes, or machine users?) and oauth2-based "sign-in-through-github" (currently targeted at private GHE instance right now).
Related to #12 except not as flexible/generic.