Hi,
I have created an API proxy.
I want that the user authenticates before using the service. Also I want that his social account is leveraged. So the flow should be the following:
User hits my service myapiproxy.apigee.com
user is redirected to Google+
User logs in if not yet logged in
Google+ asks consent to share infor with my API proxy
My proxy receives the user profile
user starts working.
Is it feasible? How to do it?
Thanks.
Yes, it is possible. You can either use, Google OAuth or Google Openid Connect to achieve this,
More information here,
https://developers.google.com/identity/protocols/OAuth2WebServer
https://developers.google.com/identity/protocols/OpenIDConnect
So basically, in your API, you need to redirect the client to Google’s auth service [oauth or openidconnect], if the request is not authorized [you could use RaiseFault policy to do that],
Google will own the authn/authoriz flow and will redirect to your API endpoint [this need to be configured as redirect URI with google], with a oauth token or a JWT.
Thanks,
Hi @Nico
I liked your question so I put together a simple example of an API Proxy that does just what you described. (Basically following along with what Mukundha suggested)
I’ve attached it here. You can deploy it to any Edge environment, and then invoke it to see it work.
The API Proxy is built with a specific set of application credentials which are registered at Google. This is an app I registered under my name at Google, on the “Google Developers Console” page: https://console.developers.google.com/project
When you GET /googauth/authorize on the proxy, it 302 redirects you to the Google signin-and-consent page. You sign in, and then Google sends a 302 redirect back to the browser, which tells the browser to invoke the /googauth/code endpoint on the API Proxy.
When that happens, the API proxy calls into Google to exchange the code for a token, and then displays the token to the browser.
After the user grants consent to this app the first time, that decision is persisted at Google. Subsequent invocations of the /authorize endpoint do not require the user going through the consent UI again. In this case Google just 302-redirects right back to /code and you get a new token with no additional consent interaction required by the user.
The API proxy also exposes a /verify endpoint. Send in the access_token and this API proxy will verify it and send back a response indicating the token is good, or a response indicating the token is no good.
You would have to modify the proxy to attach flows and targets for backend systems. But this illustrates the point.
There’s a readme in the attached zip.
ps: In addition to the opaque oauth2.0 bearer token, Google also sends back a JWT - this is another type of token. This API proxy also parses the JWT and can extract claims from that JWT that you can store and use. The JS callouts show how to do the parsing and extracting of these claims. Using those claims is an exercise left for the reader!
For now, you can see it running with MY app at: http://deecee-test.apigee.net/googauth/authorize
But it will be better for you to deploy your own so that you can Trace it and see what’s happening behind the scenes.
Thanks for the example.. I was successful loading your proxy and running it but when implementing my proxy endpoints and target endpoints, I had some questions. Your example runs completely within edge, which is fine when returning the token payload to the browser. I want to run the auth flow as an XHR from my browser client, which fails because of a lack of CORS headers. Am I approaching this the wrong way? Should I instead be chaining the flows together somehow?
ie:
Can you suggest a pattern for attaching resources to the google-oauth-flow proxy?
Thanks