@Sandeep Murusupalli
Here are some of your options:
1) Apps use IDP's OAuth tokens and authentication exclusively. Apigee calls IDP to validate on every call.
2) Apps use Apigee's OAuth tokens, and Edge calls the IDP when minting a new token. Edge stores the IDP token as a custom attribute of the Apigee token, so the IDP token can be used whenever calling a backend server that requires it.
3) Use Apigee's OAuth framework, but use the token string from the IDP as the external token.
In addition, you can add token caching for any callout to mint or validate an IDP token. In most cases, IDP validation can add significant latency to API calls, so you'll want to cache token validation if possible.
Some of the factors:
1) Does all traffic go through Apigee?
If some calls that require user auth do not go through Apigee, it can be useful to select option 1 or 3 so that the token the app sends to Apigee will also work for those other calls.
2) Do you often need to invalidate a token?
If you need to invalidate an IDP token, and you are utilizing caching for the IDP validations, you might need to also remove the token from the token cache. This can add significant complexity, but you might be able to live with access surviving a few minutes after invalidation. In addition, if the backends are validating the tokens too, and you don't invalidate the cache, you'll potentially make more calls to the backend with an invalid token, but that might be just fine.
3) Are there other tokens/authorization schemes for the backend/partner targets?
If the IDP token is not the only user auth scheme, you might need to use option 2 anyway for those other types of auth.
4) Is your IDP token completely opaque?
If your IDP token has some information built into it, you might not want to expose that to external users, and choosing option 2 where the IDP token never goes to the app might be desired.
5) Are you going to validate an API key whenever you pass a token? Do you care about the attributes for API products, developer apps, and developers?
If you are validating an API key, then the variables populated for ValidateToken (as well as the associated analytics) will already be populated by VerifyAPIKey, so validating the token externally won't cause you to lose that information.
6) Is the IDP OAuth solution truly OAuth-compliant? Does it support all the grant types you want or may want in the future?
Some IDP OAuth solutions don't follow all the OAuth rules, and may not easily support grant types other than password.
7) Do you want the flexibility to change IDPs in the future? Does your organization have multiple ways things are done?
This is a big one. By using the IDP OAuth directly, you lose some ability to change the way your auth works. If other APIs at your organization are going to use an alternative auth scheme, you don't want your app developers to have to keep separate tokens and understand different schemes. Expose one flavor of OAuth (easiest is Apigee) and hide backend auth complexity using custom attributes attached to the Apigee token.
LinkedIn
Twitter
