There are no hard & fast rules.. In that case it would be better to keep two configurations...
Will reply in detail later.... Thanks & regards, -Prabath On Wed, Oct 22, 2014 at 8:56 PM, Johann Nallathamby <[email protected]> wrote: > Making the expiry time of IDToken equal to access token in general looks > OK to me and inline with our access token implementation which is to always > issue the same token if one already exists and only reduce the remaining > lifetime. There could some cases we need to think about. > > 1. Need to think about both cases where access token expiry time is > greater than and less than IDToken expiry time. Currently we have two > separate configs for this. One possibility might be even to remove one of > those configs. I am not sure even if IDToken validity > access token > validity is a practical case. > > 2. Whats the effect with refresh_token grant type. In spec IIRC it says > issuing IDToken for refresh_token grant is optional like. Our current > implementation doesn't support IDToken for refresh grants. So what will > happen if an access token is refreshed? Could that cause any issue? To my > mind I don't see any issue. The next time you use authorization_code > grantto get an access token you will get a new IDToken with a new expiry > time matching the expiry you got using the refresh grant. > > Thanks, > Johann. > > On Wed, Oct 22, 2014 at 6:13 PM, Gayan Gunawardana <[email protected]> wrote: > >> Hi, >> >> Oauth2 access token and openid connect IDToken both contains expiry time, >> confusion is are any relationship between those values or access >> token expiry time equal to IDToken expiry time. >> >> Openid connect specification mentioned that [1] >> >> *Expiration time on or after which the ID Token MUST NOT be accepted for >> processing. The processing of this parameter requires that the current >> date/time MUST be before the expiration date/time listed in the value. >> Implementers MAY provide for some small leeway, usually no more than a few >> minutes, to account for clock skew. Its value is a JSON number representing >> the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the >> date/time. See RFC 3339 >> <http://openid.net/specs/openid-connect-core-1_0.html#RFC3339> [RFC3339] >> for details regarding date/times in general and UTC in particular* >> >> But there is no information about how this relates to access token expiry >> time. >> >> WDYT? >> >> [1] http://openid.net/specs/openid-connect-core-1_0.html#IDToken >> -- >> Gayan Gunawardana >> Software Engineer; WSO2 Inc.; http://wso2.com/ >> Email: [email protected] >> Mobile: +94 (71) 8020933 >> > > > > -- > Thanks & Regards, > > *Johann Dilantha Nallathamby* > Associate Technical Lead & Product Lead of WSO2 Identity Server > Integration Technologies Team > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777776950* > Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +94 71 809 6732 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
