Thanks Prabath. It is clear now.
Regards Roshan On Mon, Nov 20, 2017 at 6:11 PM Prabath Siriwardena <[email protected]> wrote: > Let me clarify what is solved by the encryption here.. > > Here the proxy uses the code grant type - and it gets access token + > refresh token. Proxy can either store that at server side and replicate it > across all the nodes - or store them in an encrypted cookie, and make > things stateless.. > > Encryption is used here to make the application stateless - and the end > user will not get access to the access token or the refresh token. > > Then again, if someone finds the value stored in the session storage and > then talk to the proxy API passing that along with all the encrypted > cookies through its own app (say cURL).. it will not work... > > To make the above blocked - you need to have TLS channel binding between > the browser and the proxy - and you need not to worry about APIs (whether > they support channel binding or not)... > > The other benefit proxy gives is support for CORS - you need not to worry > whether the external APIs support CORS or not... > > Thanks & regards, > -Prabath > > > On Sun, Nov 19, 2017 at 11:44 PM, Thilina Madumal <[email protected]> > wrote: > >> +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 >>>>>>>>>>>> <077%20455%203167>* >>>>>>>>>>>> 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 <077%20455%203167>* >>>>>>> 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 <077%20455%203167>* >>>>> 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 <077%20455%203167>* >>> 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 <077%20455%203167>* >> Web: <http://goog_716986954>http://wso2.com >> >> <http://wso2.com/signature> >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 <+1%20650-625-7950> > > http://facilelogin.com > _______________________________________________ > 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
