Hi all, Since we are clear with the concept behind the Proxy let's get back to the discussion of APIProxy implementation.
While researching I found that Yahoo provides an API proxy service and it adopts SQL like language. Please see [1]. In our implementation, we also can adopt the same. For an example from the SPA it just need to send a query parameter like [2] If so a request from SPA to our APIProxy will look like [3] WDYT? [1] https://developer.yahoo.com/yql/guide/overview.html [2] get name:name,age:18,city:colombo from https://some.third.party.api.com [3] https://wso2.is:9443/oauth_proxy/api_proxy?code="appIdCode"&query="get name:name,age:18,city:colombo from https://some.third.party.api.com"; Thanks, Thilina On Mon, Nov 20, 2017 at 1:29 PM, roshan wijesena <[email protected]> wrote: > 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 >> > -- *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
