Hi Hasanthi, On Tue, May 9, 2017 at 8:41 AM, Hasanthi Purnima Dissanayake < [email protected]> wrote:
> Hi Sathya, > > Does the spec [1] contains any detail about access token revocation? > > According to the Oauth 2 spec, revocation of a refresh token should also > invalidate all access tokens based on the same authorization grant. If the > token passed to the revocation request is an access token the server may or > may not revoke the respective refresh token depending on the authorization > server's revocation policy. Independent of the revocation mechanisms, the > authorization server may invalidate tokens in order to mitigate security > threats. > > It is evident that we should revoke the refresh token such that user is >> not permitted to obtain further access tokens for the application. > > > yes it is obvious that we should not allow to generate access tokens using > refresh tokens when SaaS is disabled. > > In addition to this is it required to invalidate the already-issued access >> token? > > > IMO the authorization server should revoke even already issued access > tokens when it disabled SaaS. From disabling Saas it conveys that this > application is no longer shared among other tenants. WDYT? > > [1] https://tools.ietf.org/html/rfc7009 > > Thanks, > > Hasanthi Dissanayake > > Software Engineer | WSO2 > > E: [email protected] > M :0718407133| http://wso2.com <http://wso2.com/> > > On Mon, May 8, 2017 at 11:20 PM, Farasath Ahamed <[email protected]> > wrote: > >> >> >> On Monday, May 8, 2017, Pulasthi Mahawithana <[email protected]> wrote: >> >>> Hi Sathya, >>> >>> I think it would be better to do this with a application mgt listener >>> rather than doing this at the validation time. We can use a >>> "ApplicationMgtListener.doPostUpdateApplication()"[1] implementation >>> and invalidate all the tokens issued to users from other tenants when the >>> application is updated. >>> >> >> I think we need to be careful if we go down the listener path and use >> ApplicationMgtListener.doPostUpdateApplication() method. The reason is >> that this method gets triggered even if you simply press the update button >> in the Service Provider UI without doing any change. Also what is passed to >> the method as arguments is the updated Service Provider object. >> Therefore, it is a bit tricky to figure out whether a change happened at >> all. >> >> Say, if we wrote the token revocation logic when SaaS option changes >> within this method. So whenever someone presses the Service Provider UI >> after doing a change(or not). It will be a tricky situation to figure out >> what the change was basically. (Did someone disable Saas or was it already >> off?). This method will also be called for unrelated changes like an update >> to description etc. >> >> And as of now we only remove cache entries for any update in SP triggered >> in [1]. That is safe even no change happened to SP at all. What we lose is >> the cached entries which we can retrieve from DB. But what we are proposing >> here is to revoke tokens upon an update in SP, therefore, we need to be >> careful. >> >> IMO considering that we don't have a straightforward way to identify the >> change in the update SP passed to [1] it would be better to have a SaaS >> check required places whenever the user tenant domain and SP tenant domain >> are different. >> >> or else we need to figure out a way to pass that SaaS option was changed >> explicitly. >> >> >> [1] https://github.com/wso2/carbon-identity-framework/blob/m >> aster/components/application-mgt/org.wso2.carbon.identity.ap >> plication.mgt/src/main/java/org/wso2/carbon/identity/applica >> tion/mgt/listener/AbstractApplicationMgtListener.java#L43 >> >> >> >>> >>> On Mon, May 8, 2017 at 7:03 PM, Sathya Bandara <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> This is in relation to issue [1] which happens when using a valid >>>> access token issued to a SaaS enabled application (application in a >>>> separate domain. User from another tenant domain). After disabling SaaS, it >>>> is still possible to use the same access token to access the UserInfo >>>> endpoint for this user from another tenant. Also it is possible to obtain a >>>> new access token for the saas-disabled application by using the issued >>>> refresh token for a different tenant user. >>>> >>>> For this I have added functionality to validate tenant domain and to >>>> check if the SP is SaaS enabled before granting access to the userInfo >>>> endpoint. It is evident that we should revoke the refresh token such that >>>> user is not permitted to obtain further access tokens for the application. >>>> In addition to this is it required to invalidate the already-issued access >>>> token? >>>> >>>> Appreciate your help on this. >>>> >>>> [1] https://wso2.org/jira/browse/IDENTITY-4981 >>>> >>>> Best regards, >>>> Sathya >>>> >>>> -- >>>> Sathya Bandara >>>> Software Engineer >>>> WSO2 Inc. http://wso2.com >>>> Mobile: (+94) 715 360 421 <+94%2071%20411%205032> >>>> >>>> <+94%2071%20411%205032> >>>> >>> >>> >>> >>> -- >>> *Pulasthi Mahawithana* >>> Senior Software Engineer >>> WSO2 Inc., http://wso2.com/ >>> Mobile: +94-71-5179022 <+94%2071%20517%209022> >>> Blog: https://medium.com/@pulasthi7/ >>> >>> <https://wso2.com/signature> >>> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > -- Sathya Bandara Software Engineer WSO2 Inc. http://wso2.com Mobile: (+94) 715 360 421 <+94%2071%20411%205032> <+94%2071%20411%205032>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
