Authentication

[pklaschka]

Add capabilities for authentication to allow for restricted access (in the future including roles with different permissions), allowing to secure the actual information (coming from the API) while still serving a Frontend that handles logging in / staying logged in / and so on.

Details of the proposed implementation

1. Authentication should work using the OAuth 2.0 standard as it's well known, relatively easy to implement and allows for a lot of options in the room of permissions and so on
2. Authentication should get handled by the client and should use username/password and later possibly an application token (if wanted)
3. Authentication should be required every time to protect possibly sensitive server information, i.e., tokens should not work for a long time
4. Possibly worth considering whether it's possible to integrate with "standard" implementations of it so that existing solutions on existing servers could get used when server-state gets integrated instead of used as a standalone solution.

[pklaschka]

I would like to move the actual authentication implementation (OAuth or whatever) to simple-server.

Advantages of this approach

1. Allowing for custom authentication implementations by end-users, including integrating with already existent solutions in, e.g., the company
2. Ease of integrating authentication, as adding some external library like passport.js is rather ugly inside a library. This should get managed in the server implementation, which, for us, is the simple-server
3. Future-proof: Since we then don't make the determination which Auth library to use (except for the simple-server, which just serves as an example that's ready to use), we don't have to make any decisions we might regret later when, e.g., a library stops getting maintained, which, of course, would be a catastrophe regarding vulnerabilities in the authentication system.

Proposed implementation

• Inside the config, an optional parameter called isAuthorized is passed. It has the type signature (req: ExpressRequest, authorizedGroups: string[]) => boolean and is a function that, based on the request (which could include things like a token or other Auth data) and a list of authorized groups (e.g., ['admins', 'developers'] for one endpoint and ['admins', 'developers', 'project-management'] for another) determines whether the current user is authorized to make that request. It returns true if the user is authorized and false if he/she is not.
• When the above function returns false, no code may get executed and an HTTP 403 response shall get returned
• When no authorized groups are registered for an endpoint, for security reasons, no authorization should get assumed in any case, meaning calling the method gets skipped.
• If isAuthorized is undefined or null, no authorization check shall get performed and the authorization (i.e., isAuthorized() === true) shall get assumed
• Breaking Change: authorizedGroups: string[] shall get added as third argument for addModule(), moving options: * to fourth position. These groups shall get stored and passed into isAuthorized when the module gets executed.

---

If accepted (or a modified state, if applicable) shall get added to the https://github.com/server-state/specs repository.

---

@fussel178 any thoughts?

[fussel178]

Sounds good. But for example we add a new user dynamically with his own token to check. This updates (i think) isAuthorized. Does the server-base call the new function with the new values?

[pklaschka]

@fussel178 In this case, the new user gets added to a database. isAuthorized verifies a token (or user or other credentials) with this database every time. It is basically the same as handling it inside server-base, but more flexible and easier to achieve...

[pklaschka]

Here a small sequence diagram (not really up to UML specs, but who cares 😆):
sequence diagram

[pklaschka]

Adding it to the specifications is in progress with server-state/specs#15. Since this, then, will be more of an issue of server-state/simple-server, I'll transfer the issue...