Hacker News new | past | comments | ask | show | jobs | submit login

In my services I usually use concept of identity associated with user account. Each account is allowed to have multiple identities, which can be used for credentials reset, login etc. The business data is always linked to an account, not to identity. Identities can be email, phone, username/password pair and 3rd party service account. This approach allows to fine-tune your security by customizing authentication/reset policy for each identity type and giving user enough flexibility.



I think this is definitely the way to go for any modern login system that plans to support multiple external OAuth providers in addition to its own internal email/password identity.

Decoupling the account from the identity allows users to log in to the same account with any identity provider, and have access to all the private resources associated with any external identity within that same account. Think of a storage service that aggregates user data from Dropbox, Google Drive, and OneDrive, and allows you to log in with any one of the 3 OAuth providers to access data from all 3. With a naive model that couples identity to account, this kind of identity federation would be much more difficult to support and extend to additional identity providers.

For those looking to implement support for identity federation in a microservice environment, I'd highly recommend taking a look at Dex from CoreOS: https://github.com/coreos/dex

It provides a consistent OpenID Connect based interface to multiple identity providers and identity management systems, for your backend to interact with (i.e. Dex talks to identity providers using whatever protocols they support, and your backend talks to Dex using OpenID Connect).


It's a good one, but it seems that there's a trade off with this design. Either you have to ask your users to enter all this information (not a good user experience), or, you end up with inconsistency in your model when you try to query by # number or email or any other "optional" Id's. Querying by UUID makes your app use cases fairly narrowed.


No, there's no trade-offs. From UX perspective, of course, user is not required to enter all this data. This is for his convenience, so he is required to provide bare minimum of information by his choice. However, for some functions security requirements are elevated, so he may be required to enter additional details or provide additional means for authentication.


How do you architect that, regarding DB, code and endpoints?


I usually model it so you have an Account model, which in itself is nothing more than a table with UUID and metadata like creation timestamps. Then you can have EmailIdentity, PhoneIdentity, FacebookAuthIdentity, etc. that are linked to the Account.

In a simple service you can start with just a foreign key from EmailIdentity to the Account. This allows multiple email addresses to be tied to a same account and the same account to have multiple authentication methods or identities (Facebook, email). This way you can implement e.g. changing email address by actually adding an email address and verifying it first, before deactivating the old one.

When you start to need e.g. organization accounts (think about services that have both personal and organizational aspects: Facebook with business pages and ad management, StackOverflow with companies), you can either tie the identities or personal Accounts to the organizational accounts, depending on the model you need.

It can be often useful to add Person model to the mix, which models a real person behind multiple identities / accounts, but this depends on your service.


When they sign up, they probably have to choose (at least) one of those options, so that can be included on their profile and the data can be separated from the profile. E.g. Your "profile" in the db can say "login_type: phone_number", which is supplied when you sign up or your profile is created, and then you can do a lookup on the respective table. You could likely make it simpler and just include it in the profile table (phone_number, username, email columns) since there would only be a set amount of login types (unless you somehow make it generic and augmentable from a UI).


There's nothing special from architecture perspective. Identities are necessary for login and for some tasks related to outgoing messages to user: thus, authentication (OAuth2-based server) works with identities and during the login finds the related account and grants necessary permissions for it. Resources requiring personalization (information from account), will have the account id. If they need to contact the user, they'll request message delivery by this account id - respective service will figure out, which identity has to be used for this delivery.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: