Contrib.social

JWT Invalidation on user logout

Open on Drupal.org →
Created on 7 October 2021, about 3 years ago
Updated 26 July 2023, over 1 year ago

Problem/Motivation

When you are using JWT for authentication there is always a risk that JWT tokens can be stolen and misused. JWT has some expiration date/period and in case of longer expiration period (combination with configurable expiration time) token is still valid even when you log out. So if someone get an access to the token he can use it to authenticate.

Steps to reproduce

Login user to generate a user token. Then you can login with this token adding it to the request header.

Proposed resolution

Tokens can't be literally invalidated before their expiration date, but on the internet there are some recommendations how to handle this. One of the approaches, which I chose is to create database table for storing "active" tokens (in this case hash of tokens with some other information like UID, issued date, expiration time, ...) and during authentication we can check if token is still in this table. After user logs out we can easily remove record from DB table so in next try to authentication with this token we can invalidate authentication in VALIDATE event.

As login/logout solutions are different per site / client I just prepared service for deleting user specific token (for deleting token from DB after user logs our) and also for delete all user tokens (in case user change his password) and everyone can adapt to their solution by just calling these service methods.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Needs work

Version

1.0

Component

Code

Created by

🇸🇰Slovakia phrabovcin

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇺🇸United States pwolanin

    Added some comments on the MR.

    I feel like the use case is not clearly enough defined here nor the generic need demonstrated. This seems like a good starting point, but seems like site-specific logic is going to be inolved and needed in every case anyhow?

  • Comment over 1 year ago →
    🇺🇦Ukraine andriy khomych

    Hey Peter Wolanin.
    Sorry for jumping in, I checked this MR as well. I think REAMDE should be updated with your suggestion about the use case.

  • Comment over 1 year ago →
    🇺🇸United States mwebaze

    I have been testing this module but I seem to get this exception Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: The 'access user profiles' permission is required and the user must be active. in Drupal\Core\Routing\AccessAwareRouter->checkAccess() on the rest endpoint: /user/{uid}?_format=json. The exception message doesn't seem to be very helpful as I am accessing this as an administrator but also tested it with a non-admin account. I am able to access this endpoint with this module disabled and I cannot seem to find anything in this module that would cause that exception to be thrown? Any pointers?

  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.4 & MySQL 8
    last update over 1 year ago
    11 pass
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024