Ping in Apigee Hybrid

[ven]

Hi,

Our organization is using Ping Identity for OAuth. We are using Apigee Hybrid for API Management needs. I am wondering if Apigee can Integrate with Ping Identity for User authorization and token generation instead of its own OAuth servers ? Can you share any references/articles related Apigee Hybrid and Ping integration?

This is being tracked as part of 

https://www.googlecloudcommunity.com/gc/Apigee/OIDC-with-Apigee-Hybrid/td-p/478996

[dchiesa1 · Accepted solution]

This video walks through how you can combine an OIDC-compliant Identity Provider like Ping, with Apigee.  The fact that you're using Apigee hybrid doesn't change things very much. 

The key items are:

• You can configure Apigee to trust Access tokens issued by a third-party OIDC provider like Ping, Okta, Azure AD, and others... This means a client can obtain an access token from the provider and then present it to Apigee, and with the VerifyJWT policy, Apigee can verify that access token and then make decisions about what service to provide, based on the claims in that access token. 
• It's smoother if you synchronize the client ID's between Ping and Apigee.  That way you can call VerifyJWT and then VerifyApiKey in Apigee to get full API-product authorization checks. All the coolness of API products, even though you're using a third-party token issuer.
• If you like you can implement a token exchange in the form of RFC 8693, so that Apigee will accept a JWT issued by the  OIDC IdP and return an opaque access token good only at Apigee. You'd want to do this only for efficiency with the opaque token. 

[ven]

Thanks dchiesa1. I have gone through the video. The flow we are looking at is where end user authenticates against ping and then some how sends API Key and Secret (or authorization code) to apigee to get the tokens. we do not want to store the Secret on the client side. The service callout approach mentioned in the video does not say how the API Key and Secret can be passed by Application. They are actually hardcoded in the flow. Can you share any additional documents related to each of the following options on how to achieve them? Our goal is to Authorize every front end/mobile app uniquely and identify it after the end user is authenticated against Ping.

• You can configure Apigee to trust Access tokens issued by a third-party OIDC provider like Ping, Okta, Azure AD, and others... This means a client can obtain an access token from the provider and then present it to Apigee, and with the VerifyJWT policy, Apigee can verify that access token and then make decisions about what service to provide, based on the claims in that access token. 
• It's smoother if you synchronize the client ID's between Ping and Apigee.  That way you can call VerifyJWT and then VerifyApiKey in Apigee to get full API-product authorization checks. All the coolness of API products, even though you're using a third-party token issuer.