Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
On a side note, I saw that IAM team is also building a set of SPA's [1]. The access logic is being handled from IAM side for the SPA's. If we can reuse the same IAM components we might not need to re implement in gateway side? Thoughts ? [1] - Binding access token to the browser for new IAM Portal Applications On Wed, Sep 4, 2019 at 1:42 PM Malintha Amarasinghe wrote: > 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 wrote: > >> >> >> On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga >> wrote: >> >>> >>> >>> On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby >>> wrote: >>> Hi Rukshan, On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga 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 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 >> 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.
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
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 wrote: > > > On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga > wrote: > >> >> >> On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby >> wrote: >> >>> Hi Rukshan, >>> >>> On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga >>> 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 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 > 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 |
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
Hi all, Yes, This an essential element[1] for SPA developers, If we could give this as a service in parallel to the API gateway (like a sidecar), then they could offload their burden of managing the access tokens and cookies etc to that service. In APIM 3.x , We have implemented some jaggery based proxies to handle token splitting and cxf interceptor for merging them. AFAIK @Isuru Haththotuwa has done some research/work on this topic for cellery? [1]: https://medium.com/@jcbaey/authentication-in-spa-reactjs-and-vuejs-the-right-way-e4a9ac5cd9a3 On Wed, Sep 4, 2019 at 12:35 PM Harsha Kumara wrote: > > > On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga > wrote: > >> >> >> On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby >> wrote: >> >>> Hi Rukshan, >>> >>> On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga >>> 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 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 > 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 >>>
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga wrote: > > > On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby > wrote: > >> Hi Rukshan, >> >> On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga >> 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 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 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
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
This is a feature we actually started implementation on but never completed. We should do this feature for the Microgateway. Then proxy the Store/Publisher APIs using the Microgateway itself rather than using MSF4J interceptors. On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga wrote: > > > On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby > wrote: > >> Hi Rukshan, >> >> On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga >> 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. > >> >> Thanks & Regards, >> Johann. >> >> >>> >>> Thanks and Regards >>> >>> >>> >>> On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva 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 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 > -- *Nuwan Dias* | Director | WSO2 Inc. (m) +94 777 775 729 | (e) nuw...@wso2.com [image: Signature.jpg] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby wrote: > Hi Rukshan, > > On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga > 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. > > Thanks & Regards, > Johann. > > >> >> Thanks and Regards >> >> >> >> On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva 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 >>> 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
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
Hi Rukshan, On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga 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 & Regards, Johann. > > Thanks and Regards > > > > On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva 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 >> 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] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
Hi Dushan, On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva 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". * > I meant the actual customer APIs which will be published from API Publisher and hosted on the API Gateway and managed by the API Manager. If these APIs are going to be consumed by a 3rd party SPA above protection mechanism can be useful. If we do it at the API Gateway layer, then we don't need to handle it specially in the Jaggery layer for the Store/Publisher Rest APIs. Those also can be proxied through the API Gateway and get the same protection mechanism. Thanks & Regards, Johann. > On Wed, Sep 4, 2019 at 10:47 AM Johann Nallathamby > 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 > -- *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
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. Thanks and Regards On Wed, Sep 4, 2019 at 10:54 AM Dushan Silva 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 > 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
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 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
[Architecture] [APIM 3.x.x] Supporting Cookie Based Access Tokens for APIs
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] ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
