Hi all Two options provided by Farasath is better than using refresh token all the time and creating a custom API to do both validate and refresh task.
- Using refresh token all the time is not good for performance wise. - Creating a custom API to do both validate and refresh task is not suitable because resource server does the access token validation and the refresh token call happens in between OAuth client and authorization server. So giving the refresh token to resource server seems a spec violation and security risk. Thanks and Best Regards, Saneth Dharmakeerthi *Associate Technical Lead* WSO2, Inc. Mobile: +94772325511 <http://wso2.com/signature> On Wed, Nov 15, 2017 at 11:24 AM, Farasath Ahamed <farasa...@wso2.com> wrote: > > > 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> > > > > On Wed, Nov 15, 2017 at 10:56 AM, Thilina Madumal <thilina...@wso2.com> > wrote: > >> >> >> On Wed, Nov 15, 2017 at 9:42 AM, Farasath Ahamed <farasa...@wso2.com> >> wrote: >> >>> >>> >>> >>> On Wed, Nov 15, 2017 at 9:03 AM, Thilina Madumal <thilina...@wso2.com> >>> wrote: >>> >>>> Hi Farazath, >>>> >>>> Thanks for the reply. Please see the inline comments. >>>> >>>> On Tue, Nov 14, 2017 at 11:10 PM, Farasath Ahamed <farasa...@wso2.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Tuesday, November 14, 2017, Thilina Madumal <thilina...@wso2.com> >>>>> 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 :) >> > > There are two options, > > 1. OAuth client keeps track of the expiry and does a refresh when the > token is about to expiry. > 2. OAuth client has a retry mechanism when an the resource server returns > an error when a expired token is used. > >> >> >> >>> >>> >>> >>>> 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. >> > > How about doing the id_token call always? > I mean send the id_token request to the IS whenever user does an > authenticate request. If the user is authenticated already you will get the > id_token if not user will be prompted to authenticate (A small challenge > here is the consent. That is skippable too). If the token is not valid user > will be prompted to authenticate. > > This is the same as doing an introspecting call, when the token is invalid > we redirect the user to authenticate. > > The SPA will not know it until the expiry-time specified in the id_token. > > This is a common drawback with self contained jwt tokens. This should be > solved by a notification mechanism like http://openid.net/wg/risc/ > > >> >>> >>>> >>>> >>>>> >>>>> 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: thilina...@wso2.com >>>>>> 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: thilina...@wso2.com >>>> Mobile: *+ <+94%2077%20767%201807>94 774553167* >>>> Web: <http://goog_716986954>http://wso2.com >>>> >>>> <http://wso2.com/signature> >>>> >>>> >>> >> >> >> -- >> *Thilina Madumal* >> *Software Engineer | **WSO2* >> Email: thilina...@wso2.com >> Mobile: *+ <+94%2077%20767%201807>94 774553167* >> Web: <http://goog_716986954>http://wso2.com >> >> <http://wso2.com/signature> >> >> > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
