Short Timeout on Reactive Java Microservices with Spring Boot and JHipster blogpost

[WayneP]

Greetings, I have tried to follow the example in the blogpost at
https://developer.okta.com/blog/2021/01/20/reactive-java-microservices
given by @mraible on a Windows 10 box with a Docker Desktop for Windows.

I tried the first part with Keycloak and added some blogs as the admin user, which seemed to work fine.

About five minutes after starting the Keycloak application though, an attempt to add a further blog caused the client not to respond with its typical display of all the blogs in the list.
It seemed to hang on the Create or Edit a Blog screen.

Reviewing the network response I can see a

WWW-Authenticate: Bearer error=“invalid_token”, error_description=“Jwt expired at 2021-05-17T15:25:18Z”, error_uri=“RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage”

Is the timeout for this example deliberately that short or have I failed to set some feature.

Any thoughts or guidance from anyone are very welcome.

[mraible]

A common recommendation is for access tokens to be short-lived. That’s what we have configured in JHipster. If you start your Keycloak container in Docker, and go to http://localhost:9080/auth/admin/master/console/#/realms/jhipster/token-settings, you’ll see this setting.

You could increase this value, but it’s better to use refresh tokens. To do this, update src/main/resources/config/application.yml to add offline_access as a scope.

  security:
    oauth2:
      client:
        provider:
          oidc:
            issuer-uri: http://localhost:9080/auth/realms/jhipster
        registration:
          oidc:
            client-id: web_app
            client-secret: web_app
            scope: openid,profile,email,offline_access

You might find this article helpful to understand refresh tokens. Understanding Refresh Tokens - Auth0

[WayneP]

Thanks for the rapid response @mraible
I shall have a look at the article and give your suggestion a try tomorrow.

[WayneP]

Thanks @mraible
I looked at the article, I left the access token lifespan as it was and modified my scope to

            scope: openid,profile,email,offline_access

However, I still ran into the same problem.

From looking at …

it does seem that some offline tokens are indeed generated on initial login.

I was wondering whether any further changes would be required ?

[mraible]

I didn’t think any additional changes were required, but obviously, I’m wrong. I’m sorry, I don’t know how to fix this.

[WayneP]

No worries, my friend - I appreciate your time, anyway.

I do wonder though, if refresh tokens are the way to go, is there any reason why this is not incorporated automatically into JHipster’s opinionated framework ?

[mraible]

Yes. We should fix this in JHipster. I created an issue to track and added a $200 bug bounty to it. Investigate and fix refresh tokens for OAuth with Keycloak and Okta · Issue #15069 · jhipster/generator-jhipster · GitHub

[WayneP]

Excellent - thanks Matt