1

Goal

I'd like to have multiple independent websites with one shared authentication server. The auth server will have one database in which all users are stored (just username, email and password, so different data models are of no concern). User 1 from website A should only be able to log-in at A.com, while user 2 from website B should only be able to log-in at B.com.

Question

Would it be SAFE to store the url of the website with the user record, which is the only website they should be granted access to? So for example: 
{
   username: a,
   email: [email protected]
   password: ****
   website: A.com
}, 
{
   username: b,
   email: [email protected]
   password: ****
   website: B.com
}

Why this approach

Correct me if I'm wrong, but otherwise I'd have to host a seperate database, cache and server for each website with a log-in.
Improve this question

2 Answers 2

Reset to default
0

Whether this is a 'safe' approach depends highly on the configuration of the database server itself, and not so much on the specific approach.

That said, by combining the two user groups in one data table, the compromise of either website might affect user details of other sites as well. You could consider working with a separate data table per website within one database, where for every website there is a database user with only access to that specific table.

Additionally, your approach could add unnecessary complexity: should usernames be unique per website or for all websites? Can a user on site A also have an account on site B? Should this be one or two distinct user accounts?

Improve this answer
1
  • You're right about the added complexity. I'll most likely switch to just sharing a Redis cache, since the amount of traffic is going to be low, yet I don't want to have to pay for a seperate cache for each website. Then, each website will have their own user table, since every website will have a database anyway.
    – Mike V.
    Oct 26, 2022 at 15:05
0

Having one authentication server host multiple sites is common practice. There are many third party authentication and authorization services that offer exactly that service; there are also many other open source and proprietary solutions you could consider as well. The important distinction is that by focusing only on authentication and authorization, these products are designed and backed by an entire industry dedicated to ensuring that their systems are properly securing their clients' data.

The reason I bring this up is your explanation that said you're "storing the password." That's a bright red flag you're waving, as password storage is very much not a secure practice. The news is filled with stories of ransomware, credential stealing, and account takeovers, many of which started out by an attacker accessing an insecurely designed database of credentials.

So instead of trying to build and protect an entire custom security system, consider some of the existing authentication solutions available. Systems that offer OpenID Connect (for authentication) and/or OAuth (for authorization) will give your systems good security and will add flexibility. If you build upon these you could offer your clients the ability to securely log on using their existing Facebook or Google accounts without having to even enter their passwords onto your sites.

Improve this answer
2
  • Thank you for your comprehensive reply. The reason I'd prefer a username-password approach over openID is that it'll be used for CMS's with only one user. I'd prefer giving them a username-password over having to allow only one specific (e.g. Google) account, since their access would depent on a third party service, thightly coupled to a single person. Would you still discourage me to do so if I'd: 1. Hash passwords (using a proper hashing function, not pbkdf for example) 2. Strong passwords (strict validation on e.g. password length) 3. Using a database as a service
    – Mike V.
    Oct 26, 2022 at 15:02
  • The nice thing about OIDC is that you are not limited to any one provider. You can let the user choose from any that you have a relationship with. But if you're going to store your own, at the very least use a strong password hash function like Argon2 to generate the hashes.
    – John Deters
    Oct 27, 2022 at 17:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .