Hi Roshan,
On Mon, Nov 20, 2017 at 10:43 AM, roshan wijesena <[email protected]> wrote: > Hi Thilina, > > How do you create this encrypted token? I agree with NuwanD, if you > store that encrypted token in the browser, and if some one got that token > he can > For now I'm using symetric encryption. Encrypted tokens are stored in a cookie and sent to the browser. > access your protected backed via proxy call. The point is encrypted token > seems not fixing the problem, which you trying to achieve. > So what do you suggest? You are suggesting to store the tokens at the Proxy against some key (say sessionID), and send this sessionID as a cookie to the browser-client? If so, what if this cookie is stolen? It is the same case right? > > Regards > Roshan > > On Mon, Nov 20, 2017 at 4:01 PM, Thilina Madumal <[email protected]> > wrote: > >> 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> >> >> > 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
