Simple OAuth 2 question

[#1]

The majority of our use cases are refactoring our own applications to use our own APIs - our own app would want to use our own API using an AJAX request from a single page web app - but what is the recommended way to implement this using Apigee Edge and OAuth 2.

For example - using a server side proxy (correct?)

(1) Single page web app (that we own) uses AJAX and make request to server side proxy (that we own).

(2) Server side proxy receives request and makes secure request (using secure credentials) to Apigee Edge (using which OAuth2 grant type?)

(3) Apigee Edge API Proxy makes request to real API back end service.

(4) Response comes back from real API back end service, via Apigee Edge API Proxy, via server side proxy (that we own) to single web page AJAX caller function.

But is that the best practice design? I think so - but we used 3 network hops for one request so it does not feel right. Comments/advice? Thank you.

[anilsr]

@Warwick Bailey

I don't see a need for server-side proxy, You will create an API Proxy in Apigee edge which talks to your API BackEnd service. You will implement OAuth2 in Apigee Edge which will help you to secure your APIs. API proxy created in Apigee edge will be exposed to web app / client side.

Apigee Edge free account doesn't provide white labeled API endpoint. You can use out of the box endpoint to consume in your webapp. Apigee paid plans will give you white labeled API endpoint for proxy. Keep us posted if you have any further queries / need any examples.

You can find more about OAuth2.0 & implementing same here in Apigee Docs.

[#3]

Thank you Anil.

>> I don't see a need for server-side proxy

OK - but tell me a bit more about that. If I follow your recommendation - my web app/client makes an AJAX request to API Proxy in Apigee edge. But how is that step secured?

The web app/client cannot have have a client ID/secret on the client side (for obvious reasons - the credentials could be inspected in View > Source of the web page) - so how can a secure request be sent to an API Proxy in Apigee Edge from from the web app client?

Thank you.

[anilsr]

@Warwick Bailey , I missed the point its client only app in your original question. Your comment clarified same. Yes, It's best to use thin server side proxy for same.

[anilsr]

@Warwick Bailey , I was going through this article here, which explains how to implement thin server side proxy to resolve the security issue. You can implement the same logic in Apigee Edge itself & return the access tokens after verifying credentials. So, you don't need another Server Side Proxy server instead you can use Apigee Edge to store credentials / keys in vault.

[#6]

Thank you Anil

So we have:

(1) Web app client makes Request 1 to thin server side proxy

(2) Thin server side proxy makes Request 2 to API proxy on Apigee Edge

(3) Apigee Edge makes Request 3 to back end API

and the response travels back three hops.

A question about the second step.

When the thin server side proxy makes Request 2 to API proxy on Apigee Edge (which is OAuth2 protected) - which of the 4 OAuth 2 grant types should the thin server side proxy use to call Apigee Edge?

Appreciating your responses very much - very helpful.

[anilsr]

@Warwick Bailey

Please see my comment above. Ideally, you don't need server side proxy separately. You can implement same in Apigee Edge by leveraging Apigee vault capabilities. Regarding OAuth2.0 grant types, you can find info here. I believe, client credentials should work for you.

@rdoda , @Madhan Sadasivam , @Prashanth Subrahmanyam Any thing you can add to this disucssion based on your experience ?

[#8]

OK - following along with the article from Alex Bilbie (which is excellent) - and keeping the thin server side proxy for the moment (although I understand that it is possible to implement this in Apigee Edge) - we have:

(1) Web app client makes Log In request to thin server side proxy

(2) Thin server side proxy makes request for access token using client_id and client_secret

(3) Thin server side proxy makes Log In request to Apigee Edge API proxy using access token using client credentials grant type

(4) Apigee Edge make Log In request to back end API

(5) Response returns to Apigee Edge

(6) Response returns to thin server side proxy will encrypt the tokens in a cookie

(7) Response returns to client with cookie

Subsequent requests from the client will use the cookie. The thin server side proxy will extract the access token from the cookie. The thin server side proxy will make requests to the API proxy on Apigee Edge using the access token in the client credentials grant type.

Accurate? Let me know - and I appreciate - for the sake of clarity - I am separating out the thin server side proxy from Apigee Edge - but in practice the thin server side proxy could be implemented in Apigee Edge (Really? Can all of that work on cookies and embedding tokens and extracting tokens be programmed in Apigee Edge XML policy definitions?)

[anilsr]

(1) Web app client makes Log In request to thin server side proxy with user credentials

(2) Thin server side proxy validates credentials & makes request for access token using client_id and client_secret stored in thin server side proxy to Apigee Edge

(3) Apigee Edge generates the access token using client credentials grant type, gives it back to thin server side proxy

(4) Set-Cookie header is sent in the response from thin server side proxy to client app with encrypted details of token information in the set-cookie header

(5) Client APP uses cookie header in further calls to thin server side proxy which decrypts same and forward the access token to Apigee with API request details

(6) Apigee validates the access token & sends back information to thin server side proxy which sends back same to client App

As you see, you will notice extra hops by implementing server side proxy separately. Apigee Edge gives you ability to implement same in a single proxy using out of the box policies. It's easier, quicker, better in terms of performance to implement same in Apigee edge than outside.

Keep us posted if you have any queries.

[#10]

OK - got it. That all sounds correct. Given that this is a very standard flow - almost best practice - and it can be simplified by collapsing the thin server side proxy into Apigee Edge API proxy - I would have expected sample code and details on the Apigee website instead of having to look up the (excellent) article from Alex Bilbie. Anyway - thanks for jumping in here and talking me through the flow.

On a separate point - I have one further question on API proxies with Apigee Edge.

I have a back end API service, but to protect it I use an API proxy on Apigee Edge - just like we have described. So all requests are routed through the API proxy - and the back end API service is not invoked directly by a client.

But how *is* the back end API service made not visible to clients? Why cannot a client route requests around the API proxy on Apigee Edge and directly call the back end API service?

[anilsr]

@Warwick Bailey , You will make sure backend is exposed only to Apigee Edge , It's called last mile security. Please find docs related to same here.

[#12]

Thank you Anil - very helpful. The 3 methods discussed in that document (SSL, Outbound Authentication and Node JS module) - possibly only the first is an option.

Outbound Authentication requires the back end API service to implement OAuth - which is counter-intuitive because a main reason for setting up the API Proxy in the first place was to use OAuth at the API Proxy, not at the back end API service.

Node JS module requires the use of a particular language and is too proprietary.

Which leaves the Client SSL - which is fine.

But what about a fourth option - to firewall off the back end API service to only accept requests from Apigee Edge and the API Proxy. That sounds like a reasonable option - easy to implement - but not covered by the Apigee guidance on last mile security.

Any comments on that fourth option? Is it possible with Apigee Edge? Curious to know - thank you.

[#13]

This doesn't say to implement OAuth at the backend services rather to utilise if backend APIs has any credential implementation. Most of existing services have some authentication mechanism like user credential, etc. So same can be implemented in the API Proxy to access them.

Firewall is very much permissible. IP whitelisting can be applied on the backend servers. Note that Apigee provides Edge at the cloud and API Proxy implemented at cloud access the backends services.

Could you provide detail how existing services have been exposed and what's the access mechanism.

[#14]

@Warwick Bailey, @Anil Sagar

Great discussion. One suggestion is to replace the first thin server side proxy by having URL rewrite logic at WebServer. To server static UI files like html, css, scripts, etc., there would be web server and this can add logic to add App credentials etc when requesting for access token. This will help to avoid requirement of thin proxy.

Regarding protection of backend services, one common design pattern is Edge proxy keep the access token generated by backend and provide the Edge generated token (mapped to the backend access token) to consumer App.

[#15]

Thank you - same comment as above regarding protection of back end services. It seems counter-intuitive to start having the back end API service issue and validate tokens. If we are starting to implement OAuth/token management at the back end API service - why bother with the API proxy?

>> One suggestion is to replace the first thin server side proxy by having URL rewrite logic at WebServer.

OK - but sounds very similar to the thin server side proxy. If we are scripting URL re-write logic and adding token management - then the thin server side proxy and the URL re-write scripting are converging on the same thing - we need to write a small amount of processing that runs on a web server.

[#16]

Yeah, this is sort of preprocessing logic at Web server. As web server is already there so no additional infrastructure required. Preprocessing logic is sort of dumb by just adding query params or token, it's much easier to add rather than creating another proxy.

[#17]

OK - fair point - a web server is in place for static files - so that could be reused for the URL re-write and scripting. I guess I was thinking about separating concerns and not having the web server take two roles (static file server and also API routing). Thanks for commenting.

[#18]

Hey All,

I have a question related to OAuth.

How can I do OAuth authentiaction with salesforce using my custom domain url.

Currently while authenticating it it is taking me back to test.salesforce.com, but I want to authenticate using different url, which I should be able to authenticate.

[#19]

Hey All,

I have a question related to OAuth.

How can I do OAuth authentication with salesforce using my custom domain url.

Currently while authenticating it it is taking me back to test.salesforce.com, but I want to authenticate using different url, which I should be able to authenticate.