Research Login solutions #355

New issue

Closed

opened 2026-04-16 11:06:01 +00:00 by a24vinla · 3 comments

a24vinla commented

2026-04-16 11:06:01 +00:00

Collaborator

Since we want to have users we need to solve how those users log in in a secure manner.

This research topic is quite broad. Feel free to split into sub-issues if necessary.

Links that might be useful: What is JWT

Parent Issues: #9

Since we want to have users we need to solve how those users log in in a secure manner. This research topic is quite broad. Feel free to split into sub-issues if necessary. Links that might be useful: [What is JWT](https://supertokens.com/blog/what-is-jwt) Parent Issues: #9

a24vinla added the

security

research

labels

2026-04-16 11:06:01 +00:00

c24elipe added the

Team 2

label

2026-04-16 12:22:36 +00:00

c24carso self-assigned this

2026-04-16 12:52:07 +00:00

c24carso commented

2026-04-16 13:29:53 +00:00

Collaborator

Since #9 requires user groups we need something that can handle that.

Session-based auth
Server validates credentials, stores a session server side, and gives a cookie to the client. Every time the client makes a request, it sends the cookie back and the server looks up the session to figure out who the user is and what they can do. Well supported but requires a shared session store across all services, which fits poorly with our architecture.
JWT (JSON Web Tokens)
A signed, stateless token containing info about the user like id, role etc. The client sends it in the authorization header and any service with the verfication key can validate it locally without having to go through the database. The roles can be stored in the token which lets each microservice check the permissions on its own. However this can be an issue since storing JWTs can make them vulnerable to certain attacks and revoking a token before it expires may need some workaround.
OAuth 2.0
This delegates the login to a third-party like Google. The user clicks "Sign in with Google", logs in on Google's side and Google tells our app that the user is who they say they are. We would never handle the passwords, but we still need to map the external identity to our internal role after login since Google doesn't know if someone is a Student or a Teacher. This can be combined with JWT if we use that as a base, where we issue our own token after Google confirms the identity.
Passkey
Passwordless login where you use a device PIN or biometrics like a fingerprint. When signing up, your device creates a key pair, the private key stays on the device and the server only stores the public key. To log in, the server sends a challenge that only your device can sign with the private key, proving it's you. Can be problematic if the user loses their device, so a fallback login method is needed.
OTP (One Time Password)
The user types their email, the server sends them a one-time login link or a short code, and clicking the link or entering the code logs them in. No password to remember. Simple for users but we'd need to set up some sort of email delivery system.

Summary:
I believe JWT might be the best fit for our current setup since it works well with microservices. These could be further divided, such as JWT setup, how we actually map the user to the roles and their permissions, token expiration and password storage.

### Login solutions research Since #9 requires user groups we need something that can handle that. 1. **Session-based auth** Server validates credentials, stores a session server side, and gives a cookie to the client. Every time the client makes a request, it sends the cookie back and the server looks up the session to figure out who the user is and what they can do. Well supported but requires a shared session store across all services, which fits poorly with our architecture. 2. **JWT (JSON Web Tokens)** A signed, stateless token containing info about the user like id, role etc. The client sends it in the authorization header and any service with the verfication key can validate it locally without having to go through the database. The roles can be stored in the token which lets each microservice check the permissions on its own. However this can be an issue since storing JWTs can make them vulnerable to certain attacks and revoking a token before it expires may need some workaround. 3. **OAuth 2.0** This delegates the login to a third-party like Google. The user clicks "Sign in with Google", logs in on Google's side and Google tells our app that the user is who they say they are. We would never handle the passwords, but we still need to map the external identity to our internal role after login since Google doesn't know if someone is a Student or a Teacher. This can be combined with JWT if we use that as a base, where we issue our own token after Google confirms the identity. 4. **Passkey** Passwordless login where you use a device PIN or biometrics like a fingerprint. When signing up, your device creates a key pair, the private key stays on the device and the server only stores the public key. To log in, the server sends a challenge that only your device can sign with the private key, proving it's you. Can be problematic if the user loses their device, so a fallback login method is needed. 5. **OTP (One Time Password)** The user types their email, the server sends them a one-time login link or a short code, and clicking the link or entering the code logs them in. No password to remember. Simple for users but we'd need to set up some sort of email delivery system. **Summary:** I believe JWT might be the best fit for our current setup since it works well with microservices. These could be further divided, such as JWT setup, how we actually map the user to the roles and their permissions, token expiration and password storage.

c24carso added the

needs review

label

2026-04-16 13:30:25 +00:00

j21marbr was assigned by c24elipe

2026-04-21 07:30:48 +00:00

j21marbr commented

2026-04-21 09:59:19 +00:00

Collaborator

One suggestion is to include how tokens can be less secure depending on where they are stored and why it's difficult to revoke them before they expire. It would also be good to explain more why JWT works well with our setup. It's mentioned that the token is signed and can be validated without checking the database but this could also be explained a bit more.

Good explanations that give a good overview of the different login solutions. Since JWT is recommended as a best fit for our setup, this part could be improved a bit. It's mentioned that storing JWTs can make them vulnerable to certain attacks and that revoking tokens can be an issue but this could be explained more. One suggestion is to include how tokens can be less secure depending on where they are stored and why it's difficult to revoke them before they expire. It would also be good to explain more why JWT works well with our setup. It's mentioned that the token is signed and can be validated without checking the database but this could also be explained a bit more.

j21marbr added

reviewed

and removed

needs review

labels

2026-04-21 10:01:06 +00:00