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
