I also agree that this is very beneficial for SPA apps. A couple of questions: 1. I'm not sure we can change the way the token endpoint responds in a straightforward and a backward-compatible way. Maybe we can introduce a different token API proxy for this or change the token API response based on an incoming header or something. 2. How can we set the cookie path? For Store, Publisher this is not an issue as we are using separate service endpoints and we have only one API each for each app (/api/am/store and /api/am/publisher). So we can easily set the cookie path as needed. But for the token endpoint, it doesn't have an idea which API will be called with the token so setting the path would be problematic. Setting this to "/" might be a problem as the token will be sent to unintended APIs as well. But for microgateway, I think this shouldn't be an issue if we set the cookie to the root context "/".
Thanks! On Wed, Sep 4, 2019 at 12:35 PM Harsha Kumara <hars...@wso2.com> wrote: > > > On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga <ruks...@wso2.com> > wrote: > >> >> >> On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby <joh...@wso2.com> >> wrote: >> >>> Hi Rukshan, >>> >>> On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga <ruks...@wso2.com> >>> wrote: >>> >>>> Hi Johann, >>>> >>>> If we keep the access token when generating a new token, where we can >>>> save it? Keeping in the memory will reset if the GWs get restarted. Also, >>>> we may need to keep track of each part (Map) of a token. In pub store since >>>> we need only one token at a time, this may be easy. But in the gateway can >>>> we manage this for all the tokens? Please correct me if I'm wrong. >>>> >>> >>> We don't need to store anything on the API Gateway. It will be similar >>> to how API Store/Publisher do it now - split the access token and save it >>> in 2 cookies - one "httponly" and one "non-httponly". And when it is time >>> to validate it join them back. The only difference is that we will do in >>> the API Gateway instead of API Store/Publisher so that we can use the same >>> protection mechanism for regular APIs hosted on the API Gateway. >>> >> Thanks, Johann for the explanation. So we required an additional handler >> or improvement to the authentication handler to reconstruct access token. >> > We can do the combining part easily with a handler but during token > generation this will be treat differently may be with some additional > parameter in a way that if it's present then token will be split.. > >> Thanks & Regards, >>> Johann. >>> >>> >>>> >>>> Thanks and Regards >>>> >>>> >>>> >>>> On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva <dush...@wso2.com> wrote: >>>> >>>>> Hi Johann, >>>>> AFAIK we are using #2 and a similar mechanism using jaggery for the >>>>> APIM 3.x.x store/publisher. >>>>> >>>>> I'm a bit unclear on what do you mean by *"other APIs". * >>>>> >>>>> On Wed, Sep 4, 2019 at 10:47 AM Johann Nallathamby <joh...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi APIM Team, >>>>>> >>>>>> Protecting access tokens in SPAs has been a complicated affair. >>>>>> Though there hasn't been a standard solution pattern for this problem, a >>>>>> cookie based protection approach is what most vendors follow. >>>>>> >>>>>> With APIM 3.x.x we are supporting cookie based access tokens to >>>>>> protect the API Store/Publisher Rest APIs. However, since this >>>>>> implementation has been done in API Store/Publisher backend, it cannot be >>>>>> reused for regular APIs hosted on the API Gateway. I was wondering if we >>>>>> can support this as a standard protection mechanism for other APIs as >>>>>> well. >>>>>> >>>>>> *Steps* >>>>>> >>>>>> 1. Intercept the token response from authorization server in the API >>>>>> Gateway. >>>>>> 2. Modify the token response in the gateway by splitting the access >>>>>> token and writing one half to a "httponly" cookie, and other half to a >>>>>> "non-httponly" cookie or leave it in the token response body. >>>>>> 3. When the SPA calls an API by setting part of the access token >>>>>> which it has access to, in the authroziation header, the gateway will >>>>>> join >>>>>> the other half it reads from the "httponly" cookie, and introspect with >>>>>> the >>>>>> authorization server. >>>>>> 4. The current API Store/Publisher Rest APIs can also be proxied via >>>>>> the gateway to obtain same functionality. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks & Regards, >>>>>> Johann. >>>>>> >>>>>> -- >>>>>> *Johann Dilantha Nallathamby* | Associate Director/Solutions >>>>>> Architect | WSO2 Inc. >>>>>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>>>>> [image: Signature.jpg] >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best Regards >>>>> Dushan Silva >>>>> Software Engineer >>>>> >>>>> *WSO2, Inc. * >>>>> >>>>> lean . enterprise . middleware >>>>> Mob: +94 774 979042 >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>> >>>> >>>> -- >>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. >>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com >>>> GET INTEGRATION AGILE >>>> Integration Agility for Digitally Driven Business >>>> >>> >>> >>> -- >>> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect >>> | WSO2 Inc. >>> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com >>> [image: Signature.jpg] >>> >> >> >> -- >> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. >> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > > *Harsha Kumara* > > Technical Lead, WSO2 Inc. > Mobile: +94775505618 > Email: hars...@wso2.coim > Blog: harshcreationz.blogspot.com > > GET INTEGRATION AGILE > Integration Agility for Digitally Driven Business > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Malintha Amarasinghe *WSO2, Inc. - lean | enterprise | middleware* http://wso2.com/ Mobile : +94 712383306
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
