-
Notifications
You must be signed in to change notification settings - Fork 843
Error when authorize response is missing expires_in response parameter #534
Comments
It's really OAuth2's So if the token server doesn't supply it, your client is SOL. Get a better token server :)
No, as access tokens are opaque to the client. |
I'll mark this as a bug to deal with the absent expires_in, which means the client can't proactively know when to renew the access token. |
That make sense, I didn't realize the access_token should be otherwise ignored on the client except when thrown in a header. This only came up when I switched to using SAML as the IdP for my IdP, which supplies 2 tokens only in the return URL. Thanks for checking in on it. |
I'll reopen this -- again, I think there's a bug in the sense that the code expects an expires_in. |
Alright, so in the interim, any danger in doing something like this, provided my tokens expire >900s?
PS; sorry for closing the ticket, browser only showed your first response when I closed it. |
yea, i guess hacking it for now might work. try it and let me know :) |
It certainly seems to kill the NaN bug in the refresh timers:
But, it leads to this issue when it actually tries to refresh:
So, I don't believe it to be work-around. |
I added a check that prevents loading the timers if there's no or undefined expiration. |
@bakedog417 Where you able to send the expires_in attribute with KeyCloak? We are having the same issue with implicit grant type. Without it, the automatic silent refresh does not work. |
@gitterchris No I was not able to get KeyCloak to send the expires_in parameter back-- it seems to have lost that functionality after version 3.3. What I ended up doing was defining it into a config object. Assuming you own the KeyCloak instance, you will know when the access token expires, so you can do something like this: let config = {
...
loadUserInfo: true,
automaticSilentRenew:true,
//Store user token in localstorage to stay logged in between tabs
userStore: new WebStorageStateStore({store: window.localStorage}),
//Not a real oidc-client param
expires_in:900
}; Then, later: this.mgr.signinSilentCallback(window.location.href+`&expires_in=${config.expires_in}`) and this.mgr.signinRedirectCallback(window.location.href+`&expires_in=${config.expires_in}`) Obviously, this is not the cleanest solution but it works. oidc-client will add the expires_in time to the current time to produce a "expires_at" attribute that is persisted in sessionStorage (or somewhere else if you like). This has worked out so far in that silent refreshes are working. Hope this helps! |
Thanks for your response. I have tried the same thing and it works. Anyway, KeyCloak is working on bringing back the expires_in and token_type attributes in the next release. |
Looks like KEYCLOAK-7695 has been merged and is part of Keycloak 4.4.0 :) |
I'm getting a strange issue where upon receiving my id_token and access_token, I get the following log messages:
This effectively prevents any refreshing of the tokens from my IdP. (Which is still Keycloak)
As far as I can track it down, here is where it is trying to get the "expires_in" parameter from the url? According to the OIDC docs, "expires_in" should be an OPTIONAL param. Would it make more sense to harvest that value directly from the access_token?
Or did I miss something extremely obvious again?
Thank you
The text was updated successfully, but these errors were encountered: