Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Make JWT tokens stateful even for Users / Apps - add this as a selectable option #2081

Open
drasko opened this issue Feb 15, 2024 · 1 comment

Comments

@drasko
Copy link
Contributor

drasko commented Feb 15, 2024

Is your feature request related to a problem? Please describe.

Current JWT are stateless (which makes sense in many applications for the sake of efficiency and philosophy behind JWTs), but it would be good to have a stateful option as well

Describe the feature you are requesting, as well as the possible use case(s) for it.

For some applications it is important that session is controlled, stopped and tokens can be revoked

Indicate the importance of this feature to you.

Must-have

Anything else?

No response

@rodneyosodo
Copy link
Member

rodneyosodo commented Apr 9, 2024

There are two main methods to handle user authentication, that is session-based authentication and token-based authentication.

Session-based authentication

Session-based authentication relies on a server-side mechanism that creates and stores a unique identifier for each user session. When a user logs in, the server generates a session ID and sends it to the client as a cookie. The client then sends the cookie back with every request, and the server validates it against its session store.

Token-based authentication

Token-based authentication relies on a client-side mechanism that uses self-contained tokens to store and transmit user information. When a user logs in, the server generates a token that contains the user's identity, claims, and expiration time, and signs it with a secret key. The server then sends the token to the client, which can store it locally or in memory. The client then sends the token with every request, and the server verifies it by checking its signature and validity. This way, the server does not need to maintain a session store or state.

Differences

Key Session Tokens
storage on the server on the client
state stateful stateless
Expiry handled by server handled by token itself
flexibility more flexible

Using JWT For Sessions

While JWT are commonly used for token-based authentication, they might not be suitable for session-based authentication due to security concerns. This article provides detailed insights into this matter.

Session Infrastructure

image

CREATE TABLE sessions (
	id uuid NOT NULL,
	issued_at timestamp DEFAULT CURRENT_TIMESTAMP NOT NULL,
	expires_at timestamp NOT NULL,
	authenticated_at timestamp NOT NULL,
	identity_id uuid NOT NULL,
	created_at timestamp NOT NULL,
	updated_at timestamp NOT NULL,
	access_token varchar NOT NULL,
	refresh_token varchar NOT NULL,
	active bool DEFAULT false NULL,
	device_metadata JSONB NULL,
	CONSTRAINT sessions_pkey PRIMARY KEY (id)
);

NOTE

  • We can consider employing Platform Agnostic Security Tokens instead of JWT for session-based authentication due to potential security risks.
  • Session-based authentication proves ideal for UI backend implementations, while token-based authentication serves well for communication between Magistrala core and the UI.

Proposed Approach

Change Magistrala to use session-based authentication. Magistrala issues a session token which will be used to authenticate into the system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Progress
Development

No branches or pull requests

3 participants