I would like to understand the behaviour of the id_token and access_token expiry times a little better. When my IdServer is located in the UK and the Web server is in the US, and consider a user accessing the web application through browser from singapore, my id_token and access_tokens are valid for 60 mins as per the client configuration. Is this still valid or will there be issues since the idserver and web server are in different time zones?
Currently i can see that the authentication is successful but i am not sure when the token expires.
I have verified that the token expiry is working fine as it should.
The technical explanation goes here.
Inspect the received id_token and access_token at http://jwt.io
They have the two values -
auth_time : some running number
exp: some running number.
decoding these 2 values at https://www.epochconverter.com/, we can verify the expiry of the tokens.
Related
I am very new to keycloak and want to use it for SSO, but some of our apps want to have different session expiration length, say App A is 4 hours, App B is 8 hours.
To make this work, I will need to set the keycloak to the shortest expiration time, in this case is 4 hours.
Is this the only way? Or by a long shot, keycloak can treat each client differently?
eg.
Keycloak session set to 16 hours, if request from App A, it will force user to login?
https://keycloak/oicd/login/?client_id=app_a&....
It is not clear what session means in your case. User is logged, when app has valid id/access token, which is usually short lived, e.g. 5 min and app refreshes/renews tokens periodically (for example with refresh tokens). In theory that refresh can be running indefinitely, but actually Offline Session timeouts are applied for refresh token, so it can be limited.
There is also IdP SSO session on top of that, which mean that user/app will get token without asking for user credential, when user is redirected to the IdP login page = user was authenticated recently and it still has that SSO session.
Anyway, Keycloak gives you option to customize session/token timeouts on the realm level:
Some of those timeouts can be overwritten also on the client level:
Note: there can be many dependencies, between all those timeouts, so always test your setup to see how it fits your needs. Example, how it can be complicated: How to specify refresh tokens lifespan in Keycloak
I have access token that should be valid for 10 hours, but it expires after 30 minutes. I use it to call Keycloak rest api and it works for half an hour, but after that I get 401 - Unauthorized. I decoded it on jwt.io and exp claim is 10 hours after I aquired it. I checked system time and everything seems fine. What could be the problem?
Since you have not shared your config, I am assuming you are setting "Access Token Lifespan" as 10 hours (same is reflected in your jwt as you mentioned).
To avoid the login again and again, you need to set SSO session time as 10 hours. (See 2 and 3 highlighted in below image.)
Now coming to access token, if you are using a browser to test your api, you can set it to any value less than your SSO session value. As the session cookie will be automatically handled by the keycloak.
However, if you are using PostMan or other client to test your API and want to use same token for 10 hours, then set you access token also to 10 hours.
For more details, refer: https://www.keycloak.org/docs/latest/server_admin/#_timeouts
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.
I am a little confused about calculating the time until the access token expires.
I am using server authentication (http://developers.facebook.com/docs/authentication/server-side/).
When I get the authentication code from the Facebook's request to my redirect URL, I send an authentication request back to Facebook and I get the access token along with 'expires' parameters, lately I could see that the expires is a long value that represents the time in seconds until the token expires. For some reason I think it used to be time in miliseconds.
Can I assume that the expiration time is now + expires (in seconds) - it seems to me too long (about ~5109691 seconds) - does it make sense?
Thank you for your help.
Server authenticated access tokens are valid for two months.
The value you are receiving is correct.
Edit:
https://developers.facebook.com/roadmap/offline-access-removal/
Read the 'Server-side OAuth Developers' section.
I am working with Oauth2.0. In that i could able get the access_token and instance_url. Is there any expiry time for these two.
Can I store them and use it for all my REST calls without getting the new access_token and the instance_url. Is it possible for me to use it for long hours or even days.
The access token is only valid for the length of a session (as defined in the Salesforce Org's settings — I believe the longest this can be is 8 hours without activity), as it's actually a session ID, that said, you should also be given a refresh token. The refresh token has a much longer lifetime and can be used to authenticate the user once the session has expired, without them having to enter any credentials — this allows you to do it in the background without them even having to concern themselves with the login process.
model metrics do a good job of explaining the token flow here.