3 ms·

I’m working on an application where we have separated the Authentication concerns from the rest of the user data. When a user is registered, we generate a UID a

I’m working on an application where we have separated the Authentication concerns from the rest of the user data. When a user is registered, we generate a UID and communicate that with the other services. We’re going to be using common role terminology across the services, but Authorization is up to each service in relation to those roles. Our needs are a little different as well, because each service may need to reach out to a third-party service and we are holding a bearer token for the third-party service on behalf of the user. We provide that to the services behind an auth middleware through a header. (We had considered changing this from an Auth Service to a general User Service, but I am strongly leaning toward having a separate User Service and leaving Auth tightly constrained.)

bagels 12y ago
Right, there's a few classes of data that can see that would do well to separate from the database that a website may have unfettered access to. 1) Authentication data (login id?, password) 2) Personal data that is not used in an online manner (depends on the site of course) (full name, email address, etc.) 3) Data that shows up on the site If this data is segregated in to separate silos with no 'read everything' apis exposed to the web servers, you might stand a chance of not leaking all of your users data when the web servers are compromised. This of course will not help you if the authentication servers are also compromised.