Very long-lasting access token

[Evert-Jan de Bruin]

Hello,

I am quite impressed with the features of Keycloak, but now we are facing an interesting requirement in our system. We generate caldav URLS for students of universities to view their own study schedule. Not extremely sensitive but it still needs a little bit of protection. For example something like: webdav://myuniversity.edu/calendar?student=12345678&token=abcdefgh

It needs to be a fixed URL that the student can import into their calendar client. So the URL already needs to contain a 'token' to identify the student and cannot be changed afterwards since we do not want to instruct the student to update their calendar client every x weeks or months.

I can go about this several ways:

- Increase the session duration to > 1 year and keep all these idle sessions active so the access token is still valid after more than a year. Perhaps theoretically possible, but I need to do this partly on the whole realm, plus the sessions are stored in infinispan and then need to be persisted, etc.

- Same as above, but only validate the JWT token in the application and not validate it through Keycloak (no introspect) so expired sessions are not longer the problem. Of course, not validating the token in Keycloak has disadvantages of its own. 

- Use offline tokens. However, I read that these are actually refresh tokens that themselves need to be refreshed once in a while (every couple of months). Since we have a fixed token, that is not possible.

- Just forget about Keycloak for such a particular usecase and build the token into the application itself and bypass Keycloak altogether.

 What is the recommended way to approach such a usecase?

Thanks
Evert-Jan

[dc...@prosentient.com.au]

I’m curious to hear about any Keycloak solutions for this as well.

 

For this use case, I have previously just built it into the application’s calendar endpoint.

 

David Cook

Senior Software Engineer

Prosentient Systems

Suite 7.03

6a Glen St

Milsons Point NSW 2061

Australia

 

Office: 02 9212 0899

Online: 02 8005 0595

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/ea5971a9-b20f-48fa-9ca3-a5b2df9374bdn%40googlegroups.com.

[Welton Torres]

Hi.

I see that it would be very challenging to keep auth sessions for such a large period, as (I can be wrong) keycloak doesn’t consider sessions as persistent between reboots (upgrades, Wildfly redeploys etc).

You can issue a very long lasting token for the clients and only validate it at application level (application should just check token signature, audience and claims, without token introspection at keycloak API). A problem I see with that approach is the key, because keycloak will rotate its token signature keys so you’ll have to poll for new keys and persist them at application level. That per-si is a problem, as the key can be revoked in keycloak after a 

security incident and you’ll still trust it.

- Just forget about Keycloak for such a particular usecase and build the token into the application itself and bypass Keycloak altogether. 

That being said, I suppose you should use keycloak to ensure user credentials at URL generation time and use an application issued password (token) in the URL, instead of a JWT issue by keycloak. You can keep a database of issued passwords and the iCal protected by it. You should provide a way for users to list and revoke generated URLs (lost devices, stalking ex-boyfriend etc).

[Thomas Darimont]

That's an interesting use case, thanks for sharing.

Another option could be to create your own token type that you can then validate with a custom `TokenIntrospectionProvider`, e.g. by leveraging the

`org.keycloak.protocol.oidc.TokenIntrospectionSpi` which allows you to implement your own `org.keycloak.protocol.oidc.TokenIntrospectionProvider`.

This enables you to validate your own tokens according to your rules, while still being able to use the standard introspection endpoint.

If you call the `org.keycloak.protocol.oidc.endpoints.TokenIntrospectionEndpoint` with the `token_type_hint` request parameter you can trigger your custom introspection logic. 

Your custom token could be based on a JWT (to leverage some standard and custom claims with signature support), alternatively you could also implement your own reference token mechanism.

With this in place you can handle your custom tokens on the keycloak server-side in the way you need based on the information available about the particular in the respective Keycloak realm. The existing `TokenIntrospectionProvider` implementations might serve as examples for custom implementations.

Cheers,

Thomas