-1

For a few reasons I cannot use refresh tokens on client, is it possible to implement RemoteTokenServices on ResourceServer so that it checks the token is not revoked on auth server, but get auth information like user details from JWT-token itself, not from authentication server, like default implementation does using uuid tokens?

upd: this question is not duplicate, it's about JS and general approach, I'm fine with approach I explained, I wonder if and how I can implement it using spring boot and spring security.

Tom Sawer
  • 152
  • 1
  • 13
  • Possible duplicate of [Invalidating JSON Web Tokens](https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens) – momo Jun 18 '19 at 10:18
  • 1
    AFAIK there is no built-in way. You have to implement it by yourself. – dur Jun 18 '19 at 13:30

1 Answers1

0

JWT consists of three sections:

  • Header #info about used algorithm
  • Payload #contains data, this one is important in your case
  • Signature #basically a hash of the first two items on this list

You should read about Payload (and JWT itself) here https://jwt.io/introduction

Long story short, you can include public data in the payload. If it comes to the mentioned RemoteTokenServices - sure, you can do that but I'm not sure if it's a good idea. You could just add public expiration-date (or expires) property to the payload.

Also, take a look at this: https://jwt.io/

eeqk
  • 3,492
  • 1
  • 15
  • 22
  • Thanks, though I do know about the JWT structure and purpose, may be I was not clear enough: what I need is the ability to have long running user sessions without making user to re-authenticate and the ability to end user session for security reasons on auth server. This is usually done with refresh tokens, but third party client cannot use them. So I want to check token revocation on auth server, but do not want to obtain all user information from there. I'm afraid expiration data in payload won't help me. – Tom Sawer Jun 18 '19 at 09:52
  • Unfortunately I cannot give you the exact implementation, but you could add a custom filter. The user would make a request to a specific endpoint (for example /extend-token). Then, that filter would check the validity and generate a new token or extend lifetime of the same token. However, the simplest solution to this is just giving the token nearly infinite lifetime. You should also consider security reasons of such behaviour. If someone obtains a token, that person can exploit it undefinitely. – eeqk Jun 18 '19 at 10:14