Login procedure from a helicopter view?

I want to grasp the login procedure as a principle. Basically I have no clue how to proceed if I do not get the picture from a helicopter view. ATM no details.

  1. My intention is to create a Centralized Auth Server outside the web application. Connected with a separate database with all login stuff.

  2. No new users can login unless they are “invited” in some form.

Am I on the right track or can you see something I have completely missed? Disclaimer: I have no clue what I am talking about :slight_smile:

I mean, “2” is more… 2, 3, 4…

Why are you writing “login stuff” to the Client DB? (Step 1)

Yes, I know, but at the moment I only want the big picture.

In the Client DB will only the mail and password be stored.

In the Login DB is besides mail and password also DB IP, DB name and DB Password stored. As it will be needed for the Access Token to be complete. Correct me if I am wrong!

When a new user is invited, the REST API adds this user both to Client DB and Login DB.

I have not all the details in my head yet. So I am grateful for anything that points me in the right direction!

Why does the Client DB need the password? Your Auth server is vouching for the user; your Client server doesnt need anything besides the auth server’s sayso.

Good question. I have no clear answer to this. Besides that it should be possible for the admin to edit the password for some reason. The admin will never, ever be able to edit anything on the Login DB.

So if I put the password “password1234” into the LoginDB and the ClientDB.
The Admin can change the password in the ClientDB to “notarealpassword”.
… what password does the user use to log in? They’ve got 2 now.

Both servers should be updated and the user be informed. As I said I have basically no experience so this is food for thoughts. Thank you…

I think you’ll find it simpler to isolate information to the server for which it is purposed.

The password relates only to logging in.
The admin has no ability to modify the user’s password (something like a remotely managed LDAP), OR
The admin can modify the login database.

Consider what you see a lot of websites do these days: “Log in with Google”.
The site cannot modify the password. At all. That is between the user and the authentication server, and never the site shall know.
What the site gets handed, through the trusted connection to the authentication server, is a piece of paper that says “This user has logged in with me as XYZ.”
At that point, the site can interact with its own data, using XYZ as an identifier, because they have that server’s verification paper. Literally a “voucher” - the authentication server has vouched that this communication is coming from a user that it has authenticated.

1 Like

I get your point about password. But generally speaking, do you find any basically wrong with my draft? Other than my passwords thoughts?

There’s nothing inherently wrong, its a bit of a convoluted setup for most use cases, but there can certainly be some that would benefit from it.

1 Like

Thank you for your input. I thought in this direction also. But breaking up a code into micro services with clear responsibility is simpler to understand (at least for me). And hopefully safer.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.