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 <[email protected]> wrote: > Hi Darshana, > > On Sat, Sep 28, 2019 at 8:29 PM Darshana Gunawardana <[email protected]> > wrote: > >> 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? >> > > 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 <[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 >> > > > -- > *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect | > WSO2 Inc. > (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) [email protected] > [image: Signature.jpg] > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Janak Amarasena* | Senior Software Engineer | WSO2 Inc. (m) +94777764144 | (w) +94112145345 | (e) [email protected] <https://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
