Hi Nuwan,
On Sun, Nov 19, 2017 at 8:48 PM, Nuwan Dias <[email protected]> wrote: > Hi Thilina, > > What do you gain by encrypting the token that is to be stored on the > client side? Since the client does not seem to be doing any decryption > before using the > FYI here it is not only just the access_token. It is access_token + refresh_token + id_token altogether. Token encrypted and stored in the client side to make the proxy stateless. The Cookie that posesses these data is secured and HttpOnly. > token, theft of an encrypted token could be just as bad as the one in > plain text isn't it? > All the requests for the third party APIs should go through the proxy, and proxy do the decryption and calling the APIs. This way whoever steal the encrypted token, would not be able to call the third-party API directly. On the other hand in a theft of encrypted token, we have the control to restrict the calls to third party APIs beacause all traffic should flow through the proxy. > > Thanks, > NuwanD. > > On Sat, 18 Nov 2017 at 11:37 pm, Cyril Rognon <[email protected]> > wrote: > >> Hi Roshan, >> >> IS DCR is just fine and flexible. I was just referring to the SPA use >> case without server side proxy. >> >> If I understand correctly apim server is providing this proxy endpoint to >> handle token storage or decrypt. >> >> So far it seems there is no answer to replace the api-proxy scenario. >> >> Maybe the dcr could "generate" some server side support endpoint :) ? >> >> Thanks >> Cyril >> >> >> Le 18 nov. 2017 20:54, "roshan wijesena" <[email protected]> a >> écrit : >> >> Hi Cyril >> >> Yes, I agree. AFAIK it uses a identity server DCR implementation to >> create a service provider and get a token on the fly. >> >> Do you see any problems in that approach? >> >> Regards >> Roshan >> >> >> >> On Sat, Nov 18, 2017 at 2:24 AM Cyril Rognon <[email protected]> >> wrote: >> >>> Hi Roshan, >>> >>> I have looked at the APIM 3.0.0-M7 security ilmplementation for store >>> and publisher SPAs and it seems that it is using password grant_type and >>> using "server-side" endpoints provided by apim server >>> /login/token/publisher or /login/token/store. >>> Do you agree or did I miss something ? >>> >>> Thanks >>> Cyril >>> >>> >>> 2017-11-17 6:30 GMT+01:00 roshan wijesena <[email protected]>: >>> >>>> Can you please explain more about this API-proxy ? is it only for >>>> decrypt the token? >>>> >>>> APIM 3.0.X has SPA's for it's publisher and store apps, have a look at >>>> security implementation of it. AFAIK, there is a no API proxy in that >>>> implementation. >>>> >>>> On Thu, Nov 16, 2017 at 11:06 PM, Thilina Madumal <[email protected]> >>>> wrote: >>>> >>>>> Hi Devs, >>>>> >>>>> The idea of an API-Proxy for Single Page Applications is quite helpful >>>>> in mitigating inherent security risks of keeping the access_token in the >>>>> browser side as plain text. >>>>> >>>>> Here the idea is to keep the access_token encrypted and set in a >>>>> cookie. API-Proxy will mediate all the calls for the third-party APIs by >>>>> decrypting the access_token value and calling the requested third-party >>>>> APIs with the decrypted access_token. >>>>> >>>>> This is a significantly valuable use-case for the SPAs where there is >>>>> no attached server-side other than the container which is used to >>>>> facilitate the initial page download. >>>>> >>>>> I'm in the requirement gathering phase. Would appreciate your >>>>> suggestions on, >>>>> >>>>> - what are the nice to have capabilities in API-Proxy >>>>> - what are the complexities that will arise while implementing this >>>>> - how to achieve the third-party API call mediation >>>>> - Is this a valid use-case >>>>> - or is this a redundant effort >>>>> - are there any alternatives >>>>> - and etc. >>>>> >>>>> This is an open invitation to shoot whatever pops into your mind in >>>>> this regards:) >>>>> >>>>> Thanks in advance. >>>>> >>>>> Cheers, >>>>> Thilina >>>>> -- >>>>> *Thilina Madumal* >>>>> *Software Engineer | **WSO2* >>>>> Email: [email protected] >>>>> Mobile: *+ <+94%2077%20767%201807>94 774553167* >>>>> Web: <http://goog_716986954>http://wso2.com >>>>> >>>>> <http://wso2.com/signature> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >> -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <+94%2077%20777%205729> > Best, Thilina -- *Thilina Madumal* *Software Engineer | **WSO2* Email: [email protected] Mobile: *+ <+94%2077%20767%201807>94 774553167* Web: <http://goog_716986954>http://wso2.com <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
