Google iam sso integration with apigee edge for api access.

[ranganathparvat]

Hi ,

Could you please help me to find the solution to integrate Google IAM SSO with Apigee to validate API users. this is for apigee cloud.

my organization is not recommending SAML way.

Thanks & Regards,

Ranganath P

[dchiesa1]

I'm not an expert on Google Cloud Identity, but I know a little bit. For example, I know that Google Cloud Identity supports OpenID Connect flows, in which a client app can authenticate a user via OpenID Connect, and receive a JWT id_token in response. This seems like it might be what you want to do.

In this scenario, there are numerous "actors" or participants.

• the end user
• the app (or client) the end user is tickling. This might be a third-party app. It is not trusted to handle user authentication credentials.
• the web browser (Chrome, Firefox, Safari, IE etc), aka the "User agent". In general this app is different from the client app, in that it is trusted to securely handle user authentication credentials without storing or leaking them.
• An Apigee Edge API proxy. This is also not trusted to handle user credentials.

Please note: Neither the app (the client app) nor Apigee Edge are trusted to handle the user credentials. Really those creds are secrets shared by the user, and by Google itself. The only "thing" that should handle those creds is a trusted user agent, like a mainstream browser.

With OpenID Connect, the client app "kicks off" the signin by performing a GET on a specially constructed URL. The response to this GET will be a 302 Redirect, either asking for the user to login, or affirming that the user is already logged in.

The URL is specially constructed in that

• it includes client credentials. For Google Sign in, the app that requests a user authentication must be registered with Google. It must have a Google client ID.
• it must specify a callback URL. This is registered with the client ID. The callback URL can be a platform-specific scheme intended to be caught by the mobile app, or it could be an https scheme.
• The scopes must be specified. This is the user information the app wants Google to provide, after user authentication. During the Google signin , the user approves this disclosure to the app.

To help illustrate how it works, I've build a helper form that lets you build the URL. See it here.

Keep in mind, Your user would never see that form. The form is just for aiding the developer, helping you and me understand what's happening. At runtime, the app (client app) would construct a specially-formed URL with a unique nonce and state etc, and then pop a browser window with that URL. The result would be the familiar "Sign in with Google" web experience:

After the user authenticates, Google returns a JWT id token. It looks like this:

And then the client app can send that JWT up into Apigee Edge with API requests. You can configure Apigee Edge to then verify the JWT, using the VerifyJWT policy, to be able to extract the user information and be assured that it is authentic.

If you like you could exchange that JWT for an opaque OAuth token, or... just accept the JWT as is.

Does this help?

[robert]

Wow @Dino-at-Google! Fantastic insight! From your screenshot I noticed there's session_state. For SSO, I'm wondering if that's where we can make some of that magic happen?

For instance, while a user is using my app, it could communicate (callouts/callbacks) with Google IDP and check that session is still valid?

https://developers.google.com/identity/sign-in/web/session-state

[dchiesa1]

Hey Robert-

I don't know which magic you seek. The state parameter is part of the OpenID Connect request. The spec suggests that implementors use this to keep track of requests. When the IDP issues a redirect to the callback URL, it includes the state param that was initially passed in. The receiver at the callback URL can use the state value to reconcile the incoming callback with the previously issued login request.

As for SSO.

There will be a session established in the browser. If the user is already logged in, if there is just one identity, and if the user session is active, the initial "Sign in With Google" screen won't appear, and the user will just receive an ID token via the redirect. All of that can happen in less than a second, and without any user interaction, so it would support a single-sign on motion.

I think the answer is, "it will just work". But as I said, I'm not an expert in Google Signin. So I may be missing the point of your question.