Hi Johann,
On Sat, Sep 21, 2019 at 10:43 AM Johann Nallathamby <[email protected]> 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?
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.
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.
2. 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.
Thanks,
>
> Regards,
> Johann.
>
> On Mon, Sep 2, 2019 at 12:26 PM Thanuja Jayasinghe <[email protected]>
> 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) [email protected]
> [image: Signature.jpg]
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
--
Regards,
*Darshana Gunawardana*Technical Lead
WSO2 Inc.; http://wso2.com
*E-mail: [email protected] <[email protected]>*
*Mobile: +94718566859*Lean . Enterprise . Middleware
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
