Hi Rukshan, On Wed, Sep 4, 2019 at 11:24 AM Rukshan Premathunga <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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) [email protected] >>> [image: Signature.jpg] >>> >> >> >> -- >> Best Regards >> Dushan Silva >> Software Engineer >> >> *WSO2, Inc. * >> >> lean . enterprise . middleware >> Mob: +94 774 979042 >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > -- > Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc. > (m) +94711822074 | (w) +94112145345 | Email: [email protected] > 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) [email protected] [image: Signature.jpg]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
