Hi Nuwan,
On Mon, Nov 20, 2017 at 1:54 AM, Nuwan Dias <[email protected]> wrote: > Hi Thilina, > > I still don't understand how encrypting this information makes the proxy > stateless. What state would the proxy have to bear if this information was > in plain text? Also why would you need to store the id_token on client side? > If the access_token is not stored at the browser side, then the proxy need to store the access_token against some key at the proxy side. It is same with the id_token. We need the id_token to understand the context of the access_token. In order to avoid storing tokens at the Proxy, we need to send those to the browser client. Sending them as plain text is not a wise thing to do. That's where the encryption comes in handy. However the important thing to note here is, there is no server-side for these SPAs. We don't target the web-applications with a server-side. Our focus is only pure SPAs where there is no corresponding server side. > > Yes, encrypting the token and other info would prevent an attacker calling > the APIs directly. But an attacker wouldn't be worried about calling the > APIs directly. He would just call through the proxy, just like the SPA > itself does. > If the attacker can get hold of the cookies, yes this can happen. However given that if we have secured the cookies and make them HTTPOnly we can ensure security up to some level, can't we? However if an attacker got hold of your facebook, google, or whatever cookies then he will be able to forge your identity. IMO this to happen, the attacker should either hack your machine or you should hand over the cookies willingly. Given that cookies are secured and HttpOnly, man in the middle attack or, cross-site scripts will not be able to exploit the cookies. > > Thanks, > NuwanD. > > On Sun, 19 Nov 2017 at 9:05 pm, Thilina Madumal <[email protected]> > wrote: > >> 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> >> >> -- > Nuwan Dias > > Software Architect - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 <+94%2077%20777%205729> > Anyhow, if I'm missing anything here please correct me. In order to get more insight into what we are trying to accomplish here, please refer the 17th pattern described in the blog [1]. Also please refer the slides from 18 to 24 in the presentation [2]. Thanks and Best Regards, 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
