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 <[email protected]> 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 <[email protected]> wrote:

>
>
> On Wed, Sep 4, 2019 at 12:12 PM Rukshan Premathunga <[email protected]>
> wrote:
>
>>
>>
>> On Wed, Sep 4, 2019 at 12:07 PM Johann Nallathamby <[email protected]>
>> wrote:
>>
>>> 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, 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 <[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]
>>>
>>
>>
>> --
>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>> (m) +94711822074 | (w) +94112145345 | Email: [email protected]
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: [email protected]
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Kasun Thennakoon* | Senior Software Engineer | WSO2 Inc.
(m) +94 711661919 | (w) +94 11 214 5345 | (e) [email protected]
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to