Hi all, The following is the finalized approach for API-Proxy.
API-Proxy will act as a gateway which will pass the requests coming from the SPA-client to the corresponding backend API. Before passage acces_token will be included in the request header as follows, "Authorization: Bearer <access_token>" If I'm to explain this by using an example, it would look like the following. *request from SPA-client to the oauth2-proxy: * https://hostA.com/oauth2-proxy/api/{app-session-code}/bar?name=lionels *request to the backend-api from the oauth2-proxy: * -H "Authorization: Bearer <access_token>" https://hostB.com/bar?name=lionels Here the host-mapping (hostA => hostB) is a configuration of the proxy. Appreciate suggestions and amendments. Best, Thilina. On Tue, Nov 21, 2017 at 12:48 PM, Thilina Madumal <[email protected]> wrote: > 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> > > -- *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
