Hi Thanuja, Thank you for the quick update.
On Wed, Mar 25, 2020 at 12:03 PM Thanuja Jayasinghe <than...@wso2.com> wrote: > Hi Dinali, > > Please refer "Access Token Binding Type" row in [1]. > > [1] > https://is.docs.wso2.com/en/5.10.0/learn/configuring-oauth2-openid-connect-single-sign-on/ > > Thanks, > Thanuja > > On Tue, Mar 24, 2020 at 8:40 PM Dinali Dabarera <din...@wso2.com> wrote: > >> 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> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > -- > *Thanuja Lakmal* > Technical Lead > WSO2 Inc. http://wso2.com/ > *lean.enterprise.middleware* > Mobile: +94715979891 > -- *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
