For my application we have not mentioned any explicit timeout and forms authentication cookie is set by default with expiration time 30 min and Sliding Expiration true. I came to know that the sliding expiration will reset the expiration time after 15 min.
In the cookie the only information I see is encrypted text and expiry time is not mentioned explicitly. Then How application tracks this cookie to expiration. Will the encrypted text gets updated after 15 min or is this tracking happening on server side for a particular session?
Related
I have a SSO Session Idle set to 2 min and SSO Session Max set to 3 min. After I immediately log in, in my client's session list I can see my user's session is set active. However after 2 min of being inactive, which is my refresh token's expiration time, keycloak still holds my session in active sessions list. I assume Keycloak checks verification of the token periodically and that is why my session is still being seen as active during this period. Is there a way to configure that time interval? Or is there any other reason why my session still shown as active?
I set everything to 1 just to make sure that my token is expired after 3 min and the session is not supposed to be in the list
When I try to set the access token lifespan (or any time related field, really) for a client, it only works when the specified time is lower than the time specified in the realm settings.
Let's say I have set the Access Token Lifespan, SSO Session Max and Client Session Max all to 1 day in my realm settings.
I have two clients, one public and oneconfidential.
For the public client, 1 day is fine. But for the confidential client I want to increase the Client Session Max and Access Token Lifespan to e.g. 7 days. I set this under "Advanced Settings" in the client settings in the admin console. However, this doesn't work. The expires_in from the access token response will always be 86400 seconds.
If I decrease the client specific settings to, e.g. 10 minutes, it does work.
How can I increase the the Token lifespan per client? Is it even possible? If not, is this by design or maybe a bug? (I'm using Keycloak 15.0.2).
I'd expect it to work, as I want the realm to provide "maximum security" and then only lower it per client as a conscious decision (also, hovering the ?-icon says: "If not set, it uses the standard SSO Session Max value.")
I am using a mix of a browser (Xamarin webview; to initially login and getting an access token that expires in 1 hour) and httpclient (to access my webapi endpoint). When the token expires I request a new one using the /connect/authorize endpoint using a httpclient (with the cookies copied from the webview) to get a new access token.
This works alright as long as the cookies aren't expired.
I've set up identity server to have a sliding expiration of 1 day on the authentication cookie (CookieOptions: ExpireTimeSpan/SlidingExpiration). I thought that this would result (besides getting a new valid token) in receiving new cookies on every request to the authentication endpoint, effectively keeping me logged in. The problem is that the expiry of the initial cookie that I received when logging in using the webview is used. So no matter how many times I access the authorization endpoint, I'm still logged out after a day and I can't get a new token from the authentication endpoint anymore.
Assuming I'm not completely taking the wrong approach, what requests should get me updated cookies (IdSvr? IdSvr.Session? which do I need anyway?) with a new expiry date, so I stay logged in to IdentityServer?
Note: I did take a look at refresh tokens, but these aren't available for implicit flow. And I think I need implicit flow in my case because I shouldn't save a client secret in a distributed Xamarin app. Using the cookies seems like the best alternative.
Note to self (and others): the authentication cookie is the one that's important. For the record: that's the idsrv cookie.
Then the thing that confused me during testing: calling the /authorize endpoint will only return a new authorize (idsrv) cookie when at least half the expiration time has been passed.
This surprises me a bit, because that would mean that:
8:00 log in with sliding exp of 4 hrs (expire time: 12:00)
9:59 request to /authorize endpoint (expected new expire time: 13:59)
12:01 request to /authorize again
The 12:01 request would fail miserably, because the 9:59 call did not get me an updated cookie...
Had I made de second request two minutes later at 10:01, I would have gotten an updated cookie with expire time of 14:01.
Conclusion: sliding expiration seems only be sliding when half the expiration time has passed.
Given an example here for a normal web app.
Traditionally, we use session and set timeout = 30 minutes. if session expires we will redirect user to login. (Expired time will be extended when user/browser interact with web app)
Using JWT, how to achieve that?
I know something about "token refresh", when short-time token expires it will refresh a new one using refresh-token.
But it looks like it don't care about whether user is interacting with web app or not. So as long as refresh-token is alive, the browser can always get a new short-life JWT.
So the question is: How to extend token expiring time if user is not active for a set period using JWT?
When the user interacts with your server then your server can decide to issue another JWT with a new expiration time (not at each request but e.g. 5 min before the current JWT expiration time). If the client receives a new JWT, then it replaces the old one.
When the user does nothing, no new JWT is issued and the JWT will become invalid after the timeout.
If the user is active, then issue a new JWT every time the user enter in the web application and every period of time (for example 1 hour)
If the user is not active but the browser is open, it can request a new JWT to server in background. The token must be requested before expiry time and then replace the token in localStorage or cookie. This technique also can be applied to standalone applications
If browser can not request a new token (closed, not active, etc) then the token will expire and you can redirect user to login in the some way that if server session expires
Check this JWT (JSON Web Token) automatic prolongation of expiration
If you don't set an expiration date on cookies, do they draw the expiration date from the browser settings (if there are any), or do they have a default expiration or something?
If you don't set an expiration date on cookies, do they draw the expiration date from the browser settings (if there are any)
No, if you don't set an expires header for a cookie the cookie is temporary. There are 2 types of cookies: persistent and temporary. Persistent cookies (one for which you specify the expires header) are saved as temp files on the client computer and survive browser restarts (for the duration of the expiration period or if the user clears them).
Temporary cookies on the other hand live only inside the memory of the current instance of the browser. Just as persistent cookies they are sent along each request (without expiration) but once the user closes the browser they are gone forever.