分开处理用户和身份验证逻辑还是一起处理更好？

Question

I am currently developing a codebase for all mobile projects developed by our team.

One of the main services I'm working on is the authentication service, but I am unsure about whether to treat authentication and the user together or separated, understanding authentication as all the process of obtaining and storing the authentication token (sign in, sign up and sign out), and user as the instance of that user, all its data and all the methods linked to it (CRUD of the user and related content).

Answer 1

You really want to think about authentication and authorization separately if you can. For small enough project's it's worth consolidating, but the more separation you can include the better for the future.

Just to baseline: Authentication => Who are you? Authorization => What can you do?

Authentication paradigms are almost always (these days) external, from SAML, to FIDO2, to whatever comes next... It's going to be a moving target, and you DON'T want your authorization scheme tightly tied to it. Authorization is almost always an internal concern, and should not be tied to the flavor of the week that is authentication. Not to mention the fact that it is a near certainty that you will soon be supporting multiple authentication protocols simultaneously (you aren't already?), and embedding roles based on that auth is a messy thing at best.

Also, you are at some point going to need to do something horrible, like dumping your user database and moving to a new provider. Don't make that even messier by putting all your authorization logic in there.

Finally, testing is immensely easier when you can mock authorization without authentication. Test cases will dramatically simplify if you can "impersonate" a different role on demand.

Answer 2

In any reasonably large/complex product you will have multiple domain views onto a user.

Each of these views will translate into separately stored data and logic/services for each view. The key being separation of concerns.

In order to make sure the different views can be connected it is useful to have a common identifier for a user that you may want to pass between services. But you may not need to pass a lot of additional information across the services. For example the domain services do not need to know about passwords etc.

Even in your question an authentication service may be separate from an authorization service may be separate from anything else, etc.