Hi Gayashan, I assume you are talking about Password Grant flow which generated self contained access tokens rather the default opaque tokens.
If that flow, there is no assertion involved, so we don't want to consider a "assertion expiry time" (that does not exist in this flow) when calculating the exp claim in the self contained access token. So we can remove this logic in the JWTTokenIssuer class... Please correct me if I am wrong. Thanks, On Wed, Oct 23, 2019 at 10:19 AM Gayashan Bombuwala <[email protected]> wrote: > Hi all, > > Currently, when issuing a JWT token in exchange for a password grant > assertion, we do the comparison [1]. > > When setting the "exp" claim, we check whether the expiration time of the > assertion is earlier than the expiration time defined by the service > provider. If that is the case, we set the "exp" claim of the new token to > expiration time of the assertion. > > The reason for doing this comparison is because when an IDP issue a > password grant, the IDP trusts that the original validity period will be > preserved when the Identity Server issue a new token in exchange of the > password grant assertion. > > Based on the discussion we had offline, we decided to refactor the code > where the above mentioned logic will not be carried out. > > [1] > https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/ac03fc9eeff9b183430963c5590753bd7d245e23/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/JWTTokenIssuer.java#L524 > > Best Regards, > > -- > *Gayashan Bombuwala* > Software Engineer | WSO2 > > Email: [email protected] > Phone: +94770548334 > > [image: https://wso2.com/signature] <https://wso2.com/signature> > -- Regards, *Darshana Gunawardana*Technical Lead WSO2 Inc.; http://wso2.com *E-mail: [email protected] <[email protected]>* *Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
