Hi all, Do we have an official public documents related to this approach, the token binding mechanism used and other information?
Thank you! Dinali On Wed, Nov 20, 2019 at 7:55 PM Janak Amarasena <ja...@wso2.com> wrote: > Hi All, > > Currently, there is an OAuth2 Spec[1] under development with the key > intention of sender-constraining OAuth 2.0 tokens via a proof-of-possession > mechanism. Few takeaways from that which we could also use. > We could introduce a new *token_type*[2] (like > token_type=bound+cookie) for the cookie bound access token instead of the > current bearer token as these tokens should be processed in a different way > than the normal bearer tokens. > Also if the service provider supports multiple token types we can let the > application request a token type it wants by indicating it in some > parameter when the application initiates a token requesting flow. > > [1] - https://tools.ietf.org/html/draft-fett-oauth-dpop > [2] - https://tools.ietf.org/html/rfc6749#section-7.1 > > Best Regards, > Janak > > On Thu, Oct 31, 2019 at 9:42 AM Johann Nallathamby <joh...@wso2.com> > wrote: > >> Hi Darshana, >> >> On Sat, Sep 28, 2019 at 8:29 PM Darshana Gunawardana <darsh...@wso2.com> >> wrote: >> >>> Hi Johann, >>> >>> On Sat, Sep 21, 2019 at 10:43 AM Johann Nallathamby <joh...@wso2.com> >>> wrote: >>> >>>> Hi Thanuja, >>>> >>>> Did we consider sending the access token itself as a secure, http-only >>>> cookie to the browser instead of binding it to a separate cookie? This will >>>> also simplify the development on the client side, in case someone wants to >>>> build their own SPA. >>>> >>> >>> Here which domain you assumed that the cookie will be set to? >>> >> >> I meant to the IS server domain which is the domain where the APIs are >> hosted. >> >> >>> >>> Assuming it the client's domain, there are two limitations. >>> >>> 1. Setting the token as a cookie is an additional task that client >>> had to do since OP (in this case IS) cannot set cookies for some external >>> client domain. >>> 2. Having the token stored in http-only cookie block accessing it's >>> from client-side scripts, which is a main blocker for SPAs. >>> >>> >> Not client domain. >> >> >>> >>> Assuming it the server-side domain and assuming you want to >>> automatically handle authorization for the API based on the access token >>> that already present in the cookie, there are two concerns, >>> >>> 1. This will open up CSRF vulnerability as any malicious client >>> running on the same browser can also access APIs successfully. >>> >>> Yes, your approach will prevent CSRF as well. +1. >> >>> >>> 1. If the API gateway handling authorization in back-channel mode, >>> 1. The cookie has to set to the API gateway's domain >>> 2. API gateway has to do an additional non-standard way of >>> handing this cookie and attach it to the authorization header. >>> >>> Yes, this is a possibility. But I wasn't proposing it in this case. >> >> Thanks for the clarification. >> >> Regards, >> Johann. >> >> >>> >>> Thanks, >>> >>>> >>>> Regards, >>>> Johann. >>>> >>>> On Mon, Sep 2, 2019 at 12:26 PM Thanuja Jayasinghe <than...@wso2.com> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> With the introduction of new IAM portal applications, there is a >>>>> requirement to provide additional security measures to secure these SPAs. >>>>> We have already implemented the OAuth2 authorization code flow(public >>>>> client) with PKCE for these applications and with this feature, it will be >>>>> possible to bind the access token to the browser instance. So, an >>>>> additional security measure will be enforced as the combination of the >>>>> access token and browser token(cookie) validated while accessing the IS >>>>> APIs. >>>>> Support for configuring this option using OAuth2 application >>>>> configuration and browser token persistence will be added as well. >>>>> >>>>> Updated request/response flow is as follows, >>>>> [image: Blank Diagram (1).png] >>>>> >>>>> Thanks, >>>>> Thanuja >>>>> >>>>> -- >>>>> *Thanuja Lakmal* >>>>> Technical Lead >>>>> WSO2 Inc. http://wso2.com/ >>>>> *lean.enterprise.middleware* >>>>> Mobile: +94715979891 >>>>> >>>> >>>> >>>> -- >>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect >>>> | WSO2 Inc. >>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>>> [image: Signature.jpg] >>>> _______________________________________________ >>>> Dev mailing list >>>> Dev@wso2.org >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>> >>> >>> -- >>> Regards, >>> >>> >>> *Darshana Gunawardana*Technical Lead >>> WSO2 Inc.; http://wso2.com >>> >>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>* >>> *Mobile: +94718566859*Lean . Enterprise . Middleware >>> >> >> >> -- >> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | >> WSO2 Inc. >> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >> [image: Signature.jpg] >> _______________________________________________ >> Architecture mailing list >> architect...@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > *Janak Amarasena* | Senior Software Engineer | WSO2 Inc. > (m) +94777764144 | (w) +94112145345 | (e) ja...@wso2.com > > > <https://wso2.com/signature> > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > -- *Dinali Rosemin Dabarera* Senior Software Engineer IAM Domain WSO2 Lanka (pvt) Ltd. Web: http://wso2.com/ Email : gdrdabar...@gmail.com LinkedIn <https://lk.linkedin.com/in/dinalidabarera> Mobile: +94770198933 <https://lk.linkedin.com/in/dinalidabarera>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
