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.")
Related
I have a react app where I am able to login with custom token as follows:
await firebase.auth().signInWithCustomToken(tokenResp.token);
As per this, firebase custom jwt have one hour expiry. And this is what I expect.
But when I make calls to collections that require authentication(i.e. request.auth!=null via firestore rules) after 1 hour, I am able to access them. I would expect the firebase instance to fail(automoatically) after one hour for these calls.
So why is it happening and how do I fix it?
Also note that I have logged in the jwt used to authenticate and clearly the expiry date is one hour by looking at the exp field in jwt decoder.
When the documentation states that the Custom Token (tokenResp.token in your case) is valid for one hour, it means that the signInWithCustomToken call must happened within one hour after token creation. Once the user is "signed in" (using any of the signInXXX methods), they get an access token and a refresh token, which can be used indefinitely until sign-out or revocation.
It sounds like you're trying to use Security Rules to limit access to users who have signed in within the last hour. To achieve that, inspect the auth.token.auth_time field which contains when the user has authenticated (in seconds since epoch). For example: request.time < timestamp.value(auth.token.auth_time * 1000) + duration.time(1, 'h') evaluates to true if the request time is within one hour of sign-in time. You can use that in place of request.auth!=null.
In addition, you can automatically sign users out after one hour on your client side, say using JavaScript timers and checking (await firebase.auth().currentUser.getIdToken()).auth_time as well. (Please note that this merely improves user experience on the client side and is not a substitute for the Security Rules, since client code cannot be fully trusted.)
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'm writing a client app to access some server end points I've written in PHP. I'm using JWT's for authentication, and have successfully got a working system whereby people can log in with their username/password in exchange for a JWT, which can then be used to access end points until the JWT expires.
But now I'm learning about JWT Refresh Tokens (RT) and JWT Access tokens (AT).
From what I've been reading the RT expiration time should be long, to avoid annoying repeated sign-ins, whereas the AT expiration time should be short, so that should an AT be intercepted it will most likely be unusable.
However, I'm a little confused because of the following:
When an AT expires, the client must send an RT to the server to obtain a valid AT back for use.
So the RT gets transmitted and could be intercepted or possibly found in some log. So doesn't this negate the security benefits. We still have to transmit RT's to obtain AT's, so what's more secure about using RT's and AT's as opposed to just AT's with authentication?
At present I'm thinking that AT's should only last 30 seconds or so, whereas RT's should last an hour. Perhaps my timescales are wrong and I should be thinking more along the lines of RT's last a whole week, whereas AT's last 60 minutes or something?
About security: You are right, it would not make much sense to use only one token to get another, but jwt authentication should only transmitted over HTTPS and to avoid man in the middle attacks CORS and other means (like client thumbprints) ought be used. RT's valid time must start only when AT is expired. And if you do not have to be stateless, you can e.g. save generated jwt on server and do not generate another until its expiration etc.
The timescales completely depend on the application. If its a financial system with API open to the world, times should be really short for AT and not much longer for RT, but if its a community site with no sensitive data RT should be really long for convenience is more important than top security. I hope it helps.
I'm currently setting up Keycloak to offer protection for some services. There will be both external customers and internal services consuming the same endpoints on my services.
Can I set the token expiry on a user or role or client level, or use a mix of tokens and Basic auth?
It is possible to configure a different lifespan for access tokens on a per client basis. In Keycloak admin console go to a client settings page and expand the "Advanced Settings" section.
This screenshot is taken from Keycloak 4.8.1.Final.
EDIT: Be aware that is override is applied to Authorization Code Flow only. The access token lifespan for Implicit Flow can still (Keycloak 7.0.0) be set on realm level only!
EDIT: Since Keycloak 10.0.0 it is also possible to override session idle and session max timeout per client.
It can be done on realm only, correctly mentioned by #maslick as Keycloak do SSO and expects multiple clients in one realm.
Although, you can code accordingly in your application picking the Keycloak session if you need it to be custom.
Unfortunately, token expiration time can be set on a per-realm basis only.
Can I set the token expiry on a user or role or client level, or use a
mix of tokens and Basic auth?
Currently, Keycloak does not offer (out-of-the-box) user- or role-based token expiration. IMO no one in this thread has yet covered how the SSO-related fields influence the access token lifespan. It is also missing references to ID and refresh tokens. I will try to expand on this.
Refresh Token lifespan
Currently, the refresh token lifespan cannot be explicitly set. Nonetheless, one can implicitly set the refresh token by tuning the values SSO Session Idle, Client Session Idle, SSO Session Max, and Client Session Max. One can read more about it on this SO answer.
ID and Access tokens lifespan
TL;DR One can infer that the ID and access token lifespan will be equal to the smallest value among (Access Token Lifespan, SSO Session Max, and Client Session Max).
In Keycloak (KC), one can explicitly set the access token lifespan (ATL) at the realm and client levels. Those options are not available for the ID token lifespan, but KC will make it the same as the ATL. Therefore, when one changes the ATL, one indirectly sets the ID token.
By default, the ATL is 5 minutes (except for implicit flow which is 15 minutes). One can change those values at: Realm > Realm Settings > Tokens. How it looks on the:
old KC UI:
new KC UI:
Even though the fields are labeled as 'Access Token', KC uses (as previously mentioned) their values to also set the ID Token lifespan as well.
Those values can be overridden on a per-client basis in Ones Realm > Clients > ones Client, then on the:
old KC UI, one goes to the section Advanced Settings
new KC UI, one switches to the tab Advanced and goes to the section Advanced Settings
So far so good, but now things will get a bit more interesting.
Interplay with SSO-related fields
As with the refresh token lifespan, the ATL also depends on other values, namely:
SSO Session Max
and Client Session Max.
Let us consider for now only the realm settings SSO Session Max and Access Token Lifespan, when:
SSO Session Max > Access Token Lifespan, then ATL = Access Token Lifespan
SSO Session Max <= Access Token Lifespan, then ATL = SSO Session Max
So, one can infer that the ATL is bound to the smallest value between the Access Token Lifespan and the SSO Session Max, which makes sense.
SSO Session Max is related to Single Sign-ON; we still need to consider the value of Client Session Max in the realm settings, which when unset, is the same as SSO Session Max.
If Client Session Max is set, in the context of the ATL, it will override the value from SSO Session Max, BUT only if that value is lower than the value from SSO Session Max.
Let us see the following examples: Access Token Lifespan (at realm settings) = 30 minutes, SSO Session Max = 10 hours and:
Client Session Max = 1 hour, then ATL is equal to the Access Token Lifespan
Client Session Max = 60 seconds, then ATL is equal to the Client Session Max
So in short one can infer that the ATL will be equal to the smallest value amongst the fields Access Token Lifespan, SSO Session Max, and Client Session Max.
Finally, the fields Access Token Lifespan and Client Session Max from the realm settings can be overwritten respectively by the Access Token Lifespan and Client Session Max in the clients themselves, which will affect the ATL for that client in particular.
The same logic applies but instead of considering the values Access Token Lifespan and Client Session Max from the realm settings one needs to consider those from the client advance settings.
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.