3 ms·

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

yladiz 9y ago
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).
dirtyaura 9y ago
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.
ivan_gammel 9y ago
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.

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).

dirtyaura 9y ago

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.

ivan_gammel 9y ago

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.