+Dev list On Mon, Nov 20, 2017 at 11:01 AM, Thilina Madumal <[email protected]> wrote:
> 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> > > -- *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
