On Wed, Nov 15, 2017 at 9:42 AM, Farasath Ahamed <[email protected]> wrote:
> > > > On Wed, Nov 15, 2017 at 9:03 AM, Thilina Madumal <[email protected]> > wrote: > >> Hi Farazath, >> >> Thanks for the reply. Please see the inline comments. >> >> On Tue, Nov 14, 2017 at 11:10 PM, Farasath Ahamed <[email protected]> >> wrote: >> >>> >>> >>> On Tuesday, November 14, 2017, Thilina Madumal <[email protected]> >>> wrote: >>> >>>> Hi Devs, >>>> >>>> I'm working implementing an SPA that uses OAuth access-token in >>>> securing resource access. >>>> In the documentation [1] I found that to validate the access token that >>>> I already have obtained, the introspection endpoint can be used. >>>> >>>> My question is, is there a way where I can send both the accesss token >>>> and the refresh token, then IS will validate the access token, and if the >>>> access token is expired IS will issue a new access token for the given >>>> refresh token. >>>> >>>> I understand that the above use-case can be achieved by 2 requests to >>>> the IS. But I'm curious is to know whether there is a way to achieve this >>>> by a single request. >>>> >>> >>> Introspection Endpoint is basically an endpoint used to gather validate >>> and gather metadata about the access token. >>> >>> Usually this will be used by a resource server to validate an access >>> token presented by an oauth client. Resource server will introspect the >>> token to get metadata and authorize access. >>> >>> Meanwhile, a refresh token flow is between the oauth client and >>> authorization server. >>> >>> So the requirement you have presented does not fit into the >>> introspection call/endpoint. ie. Introspection and token refresh in one >>> call simply because there are two completely different flows. >>> >> >> In end-user perspective this would be a nice to have feature unless it is >> not a spec violation. >> On the other hand it do not need to be the introspection endpoint, it can >> be some custom endpoint where it takes the access-token and refresh-token >> and has the following behavior; >> >> - if the access-token is still valid return the same accesss-token >> and refresh-token. >> - if access-token is expired exchange the refresh-token for a new >> access-token, and return the new access-token and a new refresh-token. >> >> Okay in that case we can go for a custom grant type. Grant type will > accept an access token and a refresh token and have the behaviour you have > described. Anyways if the requirement is to make sure we have an active > token all the time why not simply refresh the token :) > Is it a recommended approach? I mean refreshing the access-token frequently. Just asking for the curiosity :) > > > >> Anyhow need to consider the practicality of the use-case furthermore. >> >> >>> >>> In you use case why does the SPA have to do the introspection call? >>> Shouldn't it be the resource server consumed by SPA that needs to do the >>> introspection call. >>> >> >> In this particular use-case the IS is the resource server. The SPA is a >> fully browser based application. >> To verify the authenticity of the user the SPA uses the access-token it >> obtained, that's why the SPA needs to call the introspection endpoint. >> > > From what you have explained. To me IS is the authorization server. SPA is > the OAuth2/OIDC client. Since the SPA will recieve the id_token which is > signed by IS. We should use that to verify the authenticity of the user. > Moreoever user details in an instrospection call is optional so we can't > rely on it to authenticate the user where as id_token is tailored for user > authenticationa and guranteed to contain the identifier of the user as > 'sub' claim. > Yep we can use the use the id_token (expiry timestamp that is specified in the id_token) to verify the authenticity. My only concern here is what if manual revocation of the access_token took place. The SPA will not know it until the expiry-time specified in the id_token. > >> >> >>> >>> If the resource server throws an error due to an invalid access token >>> then the SPA can do the refresh call and get a new token. >>> >>>> >>>> [1] https://docs.wso2.com/display/IS530/Invoke+the+OAuth+Int >>>> rospection+Endpoint >>>> >>>> Best, >>>> Thilina >>>> -- >>>> *Thilina Madumal* >>>> *Software Engineer | **WSO2* >>>> Email: [email protected] >>>> Mobile: *+ <+94%2077%20767%201807>94 774553167* >>>> Web: <http://goog_716986954>http://wso2.com >>>> >>>> <http://wso2.com/signature> >>>> >>>> >>> >>> -- >>> Farasath Ahamed >>> Software Engineer, WSO2 Inc.; http://wso2.com >>> Mobile: +94777603866 >>> Blog: blog.farazath.com >>> Twitter: @farazath619 <https://twitter.com/farazath619> >>> <http://wso2.com/signature> >>> >>> >>> >>> >> >> >> -- >> *Thilina Madumal* >> *Software Engineer | **WSO2* >> Email: [email protected] >> Mobile: *+ <+94%2077%20767%201807>94 774553167* >> Web: <http://goog_716986954>http://wso2.com >> >> <http://wso2.com/signature> >> >> > -- *Thilina Madumal* *Software Engineer | **WSO2* Email: [email protected] Mobile: *+ <+94%2077%20767%201807>94 774553167* Web: <http://goog_716986954>http://wso2.com <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
