Integrating Google CICP with Apigee for OIDC flows

Google has released Cloud identity for customers (CICP). I would like to use it to implement an OIDC flow. Basically, I want CICP to be the identity provider and Apigee to be the resource owner. A user accesses our app(client), they are redirected to use CICP to create an account and login, and once logged in, I'd want CICP to issue the necessary ID and access tokens for Apigee to consume to allow access to APIs consumed by the app. CICP doesn't need to generate the tokens, but the whole use case needs to be completely OIDC compliant, so either Apigee or CICP should generate them.

Many thanks for all your answers.

0 1 485
1 REPLY 1

Google Signin already does OIDC.

I believe CICP uses the same endpoints and authentication mechanism used by Google Signin. If that's true then everything is super easy.

This signin page allows you to exercise the Google Signin with OpenID Connect.

Basically it provides a form for you to fill out, and on the basis of that form, the page itself dynamically constructs a signin link. An HTTP GET sent to the "kickoff" link will receive a redirect from Google, and following that redirect (As browsers will do automatically) will open a login form. this is a real login form and you can authenticate using any "Google" credentials. Any creds you use to signin to gmail or youtube or other Google properties.

Take care: Any time you visit a random link posted on the internet you should be careful, and especially when you visit a link that asks you to authenticate. But the form I linked to, above, does not store any data. It does not retain any of your information. IT COULD, and so you need to be careful.

Filling out that form and then clicking the link, and then logging in... will result in an id token being sent back to the redirect page. That means I can get at all the information in your id_token, including your first and last name, and your email. The form can't ever see your credentials of course; that's the point of OAuthV2 authorization code flows (and OIDC). In fact if you follow through with logging in, you'll see the redirect page which displays all that information to you. I'm telling you that this sample does not store any information, but, as always if you are super cautious, don't login and grant consent.

To fill out that form, use these values:

client id 671646694294-2e6h95mkgafps8b5qh1us2hajlptqj8q.apps.googleusercontent.com
client secret c3NPLQnwJlN1D891-N4yKg8R
callback uri https://dinochiesa.github.io/openid-connect/goog-reply.html
response type id_token
scope openid, profile, email

You can use anything at all for nonce and state.

After you fill out the form, alt-click on the link at the bottom of the page. That opens the login in a new browser tab. The redirect page that displays after you login will show all the contents of the id_token.

This form is just an illustration. An aid to understanding for developers. It's not something you would ever put in front of a regular user. If you choose to build an app that uses openid connect, then you would just embed the login link as shown at the bottom of the page, into your app, using your own client id and secret.

Keep in mind: there is no Apigee Edge involved at this point!

The id_token then gets sent back to the original client app. That app can then send the id_token to an Apigee Edge API endpoint, which can verify the signature on that id_token, using the VerifyJWT policy.

When the id_token is verified, the API Proxy can rely on the values contained in the id_token. You can then design the API Proxy to issue an opaque OAuth token to the client app, who holds a valid id_token.

Lots of other options. I look forward to your additional questions.