1:37 p.m.
Hey everybody,
As you might know I’m working on the Hawkular Android Client project [1].
If you tried to run the application you might saw that we are using OAuth
to get access to Hawkular instances because basic auth is too barbaric.
For testing purposes I use the Docker container named jboss/hawkular-aio
[2] with Hawkular 1.0.0 Alpha 3.
Keycloak provides two types of auth tokens. First—a regular one, expires
after 5 minutes by default. Second—a refresh one, which is used to refresh
a regular one, expires after 30 minutes by default. The thing is, it seems
like Keycloak refreshes refresh tokens, i. e. refresh tokens can expire.
All tokens, including the refresh one of course, are refreshed in the
refresh procedure. In practice it means that if you don’t use the
application for an hour, for example, you are forced to relogin, because
you have no ability to refresh tokens. This sounds weird and personally I
would be pissed to relogin basically every time I use the application.
Am I right? Is this a proper behaviour? Can it be avoided without
reconfiguring Keycloak? Who are we in this world? These are the questions
:-)
Artur.
[1]: https://github.com/hawkular/hawkular-android-client
[2]: https://hub.docker.com/r/jboss/hawkular-aio/
3:20 a.m.
Artur,
See inline.
On 08/17/2015 08:37 PM, Artur Dryomov wrote:
Am I right?
Yes.
Is this a proper behaviour?
Depends on what is deemed as "proper". It's the current behavior, yes.
Can it be avoided without reconfiguring Keycloak?
No. Even if the refresh token is configured to not expire, it will
expire should the user perform a logout. In other words: every refresh
token needs an active user session, otherwise it's understood that it
has expired.
We have a JIRA to track this on Hawkular side:
https://issues.jboss.org/browse/HAWKULAR-259
Based on conversations I had with Stian (from the Keycloak team), the
required support on Keycloak side should be there in 1.5, to be released
in a couple of months.
Who are we in this world?
That's a difficult one and I'll let other more experienced people answer it.
- Juca.
4:21 a.m.
Thank you for the answers.
No. Even if the refresh token is configured to not expire, it will expire
should the user perform a logout. In other words: every refresh token
needs
an active user session, otherwise it's understood that it has expired.
Is it possible to configure the session length to a longer period by
default then? 30 minutes seems very little and, as I’ve mentioned, will be
(very) frustrating for users.
5 a.m.
On 08/18/2015 11:21 AM, Artur Dryomov wrote:
Thank you for the answers.
No. Even if the refresh token is configured to not expire, it will
expire should the user perform a logout. In other words: every
refresh token needs an active user session, otherwise it's
understood that it has expired.
Is it possible to configure the session length to a longer period by
default then? 30 minutes seems very little and, as I’ve mentioned, will
be (very) frustrating for users.
I'm afraid it wouldn't solve the problem. Instead of 30 minutes, we
could use another "reasonable" value (60, 90 minutes), and it would be
almost equally frustrating. Increasing this value too much (8h, 1w),
however, is a security concern.
I'd suggest to watch the JIRA I mentioned before and switch the client
in the future to use those permanent tokens. Unfortunately, there's no
good short-term solution.
- Juca.
3418
days inactive
3419
days old
3 comments
2 participants
participants (2)
-
Artur Dryomov -
Juraci Paixão Kröhling