There's a few things we could do: * Expand the public realm REST interface to include information about timeouts * oauth alreayd requires that access token response json document contains an access token timeout, we could include the refresh tieout too. * Then again, you could just decode the refresh token :) On 10/15/2014 11:20 AM, Corinne Krych wrote: > Hello Keycloak > > Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are: > - renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4, > - expirable, which is more a surprise to me. (nothing like that in oauth2 spec) > > So for iOS sdk we’ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we’ll need to go through grant ptopup again. > To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired” or decode refresh token as done in key cloak.js [3]. > > Thanks @mposolda for the links. > > @summers @passos: I guess it’s something you’ll need to consider too for Android sdk. > > ++ > Corinne > —————— > AeroGear iOS tech lead > > [1] https://issues.jboss.org/browse/AGIOS-294 > [2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth... > [3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/..., https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/... > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Submit a jira please. On 10/15/2014 12:04 PM, Corinne Krych wrote: > if you asked me, i think providing expiration date in json response (i.e.: second choice in your list) makes it clear that refresh tokens do expire and it's easier on client side refersh token dealing (not need to decode tokens etc…). > > ++ > Corinne > > On 15 Oct 2014, at 17:35, Bill Burke <bburke(a)redhat.com&gt; wrote: > >> There's a few things we could do: >> >> * Expand the public realm REST interface to include information about >> timeouts >> * oauth alreayd requires that access token response json document >> contains an access token timeout, we could include the refresh tieout too. >> * Then again, you could just decode the refresh token :) >> >> On 10/15/2014 11:20 AM, Corinne Krych wrote: >>> Hello Keycloak >>> >>> Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are: >>> - renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4, >>> - expirable, which is more a surprise to me. (nothing like that in oauth2 spec) >>> >>> So for iOS sdk we’ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we’ll need to go through grant ptopup again. >>> To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired” or decode refresh token as done in key cloak.js [3]. >>> >>> Thanks @mposolda for the links. >>> >>> @summers @passos: I guess it’s something you’ll need to consider too for Android sdk. >>> >>> ++ >>> Corinne >>> —————— >>> AeroGear iOS tech lead >>> >>> [1] https://issues.jboss.org/browse/AGIOS-294 >>> [2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth... >>> [3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/..., https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/... >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com