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]
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
