[OAuth2] User is logged out after access token has expired

Overview of the issue

Within our generated application, users seem to be logged out after 30 minutes, even if they have been using the application the whole time.

Motivation for or Use Case

Our application will be used by employees during their day. We don’t want them to re-login every 30 minutes. On the other hand, simply increasing the timeout will not solve the issue with unexpected logouts.

Reproduce the error

1. Login as any user
2. Work with the application for 30 minutes
3. Suddenly a request will fail and you will be logged out

We also experienced a rare but harder case:

1. Login as any user
2. Logout
3. Login again 29 minutes after the first login with the same user
4. You will be logged out after 1 minute (the same access token is returned)

Related issues

Could not find anything related.

Suggest a Fix

Spring already issues a refresh token in addition to the access token. The Angular client could use the refreh token to fetch a new access token. This would be possible in advance (i.e. every 29 minutes) or on-demand (i.e. before each server call, check if access token is valid and - if not - refresh it first) or on-failure (intercept 401 responses and retry after refreshing the token). I think the last one would be the best solution but I’m not sure.

JHipster Version(s)

4.6.2

JHipster configuration

{
  "generator-jhipster": {
    "promptValues": {
      "packageName": "de.XXX",
      "nativeLanguage": "de"
    },
    "jhipsterVersion": "4.6.2",
    "baseName": "XXX",
    "packageName": "de.XXX",
    "packageFolder": "de/XXX",
    "serverPort": "8080",
    "authenticationType": "oauth2",
    "hibernateCache": "no",
    "clusteredHttpSession": false,
    "websocket": false,
    "databaseType": "sql",
    "devDatabaseType": "h2Memory",
    "prodDatabaseType": "oracle",
    "searchEngine": "elasticsearch",
    "messageBroker": false,
    "serviceDiscoveryType": false,
    "buildTool": "maven",
    "enableSocialSignIn": false,
    "clientFramework": "angularX",
    "useSass": true,
    "clientPackageManager": "yarn",
    "applicationType": "monolith",
    "testFrameworks": [
      "protractor"
    ],
    "jhiPrefix": "jhi",
    "enableTranslation": true,
    "nativeLanguage": "de",
    "languages": [
      "de"
    ]
  }
}

Entity configuration(s) entityName.json files generated in the .jhipster directory

not relevant

Browsers and Operating System

Chrome on Windows

• Checking this box is mandatory (this is just to show you read everything)

[ghost]

@jdubois I do not thing its a best solution. Client already store somewhere refresh token (cookie or local storage) so when you get 401 then you should try to get new access token. This solution should be implemented in http interceptor. I have created something for angular1 and works fine.

[dkefer]

@jdubois : I do have this issue with a freshly generated application (JHipster 4.13.1) and Keycloak.

If I try to e.g. fetch an entity from a microservice after 5 minutes from login, I get 401. The docker-compose console says:

keycloak_1              | 13:59:57,066 WARN  [org.keycloak.events] (default task-15) type=USER_INFO_REQUEST_ERROR, realmId=jhipster, clientId=null, userId=null, ipAddress=172.18.0.9, error=invalid_token, auth_method=validate_access_token
requirement-app_1       | 2017-12-30 13:59:57.076  WARN 6 --- [ XNIO-2 task-13] o.s.b.a.s.o.r.UserInfoTokenServices      : Could not fetch user details: class org.springframework.security.oauth2.client.resource.OAuth2AccessDeniedException, Unable to obtain a new access token for resource 'null'. The provider manager is not configured to support it.

I can still fetch data from the gateway though (e.g. http://localhost:8080/api/gateway/routes/ still returns 200). I’ve noticed that the browser sends only JSESSIONID.

My guess what happens is that gateway maps this JSESSIONID to the access token (AT) and sends that AT to the microservice. After 5 minutes the microservice fails to validate it with Keycloak (as the AT is not renewed, neither by the client nor the gateway).

Would you like me to open a new bug for this?