Transition to JWT Authentication

[ajmeese7]

This PR is part of a series intended to improve security for the authentication flow for OS.js. Storing a cookie with the cleartext username/password combination on the client side is not a safe method of authentication, and this PR is intended to help resolve that issue.

[andersevenrud]

Storing a cookie with the cleartext username/password combination on the client side is not a safe method of authentication, and this PR is intended to help resolve that issue.

I don't understand this part. The default authorization with cookie only stores a "session id" that is validated on the server each request. No credentials are exposed.

[ajmeese7]

OS.js stores the stringified username/password in a client-side cookie (reference) for use in authentication. This is insecure and should be avoided, as is explained in this thread. Additional information can be linked if necessary.

This is the server-side portion of the three PRs that will be made, it is still a draft until the client-side and main OS.js PRs are opened.

[andersevenrud]

OS.js stores the stringified username/password in a client-side cookie

Ah, you're referring to the auto-login.

os-js/OS.js#761 (comment)

[ajmeese7]

Correct, I am replacing the username/password based autologin with the ability to use a JWT refresh token to create another access token. This should replace the insecure cookie login and be the more secure default alternative, ideally.

Sorry if that was unclear before :)

[andersevenrud]

I understand now. And this is exactly what I wanted in the issue I linked (and is for example how the Auth0 adapter I made works) :)

[ajmeese7]

@andersevenrud as we discussed, the code has been pushed to make it easier to review. I am going to request your review since I know that changes will be required before this is merged, I just have not yet had the time to get to them.

[andersevenrud]

Here's my preliminary feedback. Let's tackle this and then I'll do another pass :)

[ajmeese7]

@andersevenrud I believe all of the requested changes have been made

[andersevenrud]

Note to self: Check out how I integrated Auth0 Auth adapters because some of the features added here potentially needs a way to be overridden so that there's not two token mechanisms on top of each other.

[andersevenrud]

Note to self:

JWT however is immutable. You put the session data into the token on login, and that's it.

Does this have an impact on any current users ? The manual and examples contains stuff that demonstrates how to mutate the session for doing arbitrary stuff on the back-end with service providers and applications.

I.e.: is there a need to issue new tokens if that's the case ? This scenario would require new mechanics in the client.

Also, related to arbitrary stuff; what about secrets that's technically secure with the cookie mechanism, but now would be clear text in the token ?!