Developer App on Apigee and Azure/Okta - Sync up & Authorization

[asharma377]

hi Most idps such as azure and okta are allowing developer apps to be created on their platform.

What is the criteria to decide whether we create the developer app on Apigee vs Okta/Azure (take client credentials flow only). What are the advantages to create the app on Okta/Azure.

If i have an app on Okta etc that gives me token. I would still need to create an app on Apigee which i would associate with API Product(i.e Resources). Is the approach to have two apps being used by other members in apigee projects?

what would be the role of Okta/IDP here then only is it to generate token. Can i also associate resources in terms of Apigee Endpoints also there.

In previous post answered by @Dino-at-Google he mentioned to synchronize client id/ secrets so we maintain only single pair

https://docs.apigee.com/api-platform/publish/import-existing-consumer-keys-and-secrets

Is this something done using custom scripts?

I have also referred to the help doc -

https://docs.apigee.com/api-platform/security/oauth/use-third-party-oauth-system

I think here the generation of token request routes through Apigee and it communicates to the IDP using externalauthorization=true.

For authorization it is recommending here to use OAuthV2 policies as the token was generated via Apigee so it is was stored and can be verified.

So this is different from the usecase i mentioned as in our case client would have already got the token from IDP, and then when it comes to Apigee it needs to validate the same and allowed access to resource.

In the previous posts priyadarshi mentioned implementing the use-case i mentioned

https://community.apigee.com/questions/88720/client-credentials-provided-by-azure-ad-vs-apigee.html

Don't want to confuse but there could also be complications if we get Devportal also in to picture where developers can create their own apps on Apigee and associate Apps. This app would be on apigee and may not have it's counter part on Okta/Azure.

I am unsure how these apps on two different systems would by in-sync and what are the best practices keeping different oauth grant types in consideration.

Please share your thoughts.

thanks,

Aakash

[dchiesa1]

This is a very interesting question. @Miguel Mendoza may have an opinion.

[kurtkanaskie]

This is also a very common question.

One way to approach this is through a series of questions that make up a decision tree which leads to design patterns. The beauty of Apigee is its flexibility, so you can support whatever decisions you need, but that means the decisions are yours to own and manage, including the implications.

Let's consider your use case, client credentials. Here's a fragment of a decision tree for that case.

The full tree can be found here: https://github.com/nas-hub/Apigee-Enterprise-Security-Design-Patterns/tree/master/IAM-Integration

• Decision 1 - End-User Auth - No, since this is just client credentials
• Decision 2 - N/A
• Decision 3 - App Authentication
  
  • Apigee - This is the most straight forward and out-of-the-box solution. Apigee creates and manages the App keys. This supports App Developer self-service registration and App creation on the Dev Portal without any extra configuration.
  • IdP - Leads to decision 4
• Decision 4 - API Token Authority
  • Apigee - Apigee creates the access tokens natively using the external App keys.
    • IMPLICATION: External App keys are imported into Apigee to use as its own. Then the OAuth flow is as if the keys where generated by Apigee.
    • CONSEQUENCE: Disrupts the built-in self-service flow to allow for the external keys to be assigned to the App, which involves external intervention (e.g. manual script or cron job of some sort). Importing keys can be done with just a few Edge API calls:
      • Create / Assign the external keys to an App
      • Assign the keys to an API Product
      • Delete the original keys
      • Notify developer that keys are available
  • IdP - External IdP owns App keys and creates the access token.
    • IMPLICATION: Developers use external Dev Portal and somehow account for Apigee's API Products during App registration. External App Developers, Apps and keys should be imported into Apigee to support analytics.
      • If OAuth is initiated through Apigee it calls out to external IdP to create an access token, which can then be used "as the value" of the Apigee token (via ExternalAccessToken and ExternalAuthorization properties).
        • If OAuth is initiated through the external IdP, a shared flow can be used to validate the external access token and then use it "as the value" of the Apigee token as noted above.
    • CONSEQUENCE: Precludes use of Apigee Dev Portal for App developer registration and App creation process. In addition to importing App keys, App Developers and Apps can be imported with a few more Edge API calls.

These decisions are similar if User authentication if required.

Considering the API consumer experience, using both Apigee Dev Portal and Apigee OAuth APIs would provide the least friction and most holistic solution.

Bottom line, you have options and Apigee has the flexibility to do what YOU choose to do.

Hope this helps.

[dchiesa1]

Nice answer!

One addendum. Regarding this comment:

IdP - External IdP owns App keys and creates the access token.

...

CONSEQUENCE: Precludes use of Apigee Dev Portal for App developer registration and App creation process. In addition to importing App keys, App Developers and Apps can be imported with a few more Edge API calls.

One of our colleagues, @Sai Saran Vaidyanathan, has produced a demonstration that shows linkage of the IdP and the developer portal via audit triggers. This allows people to use the Apigee Dev Portal for developer and app registration, while allowing the IDP to "own" and provision the keys. (and optionally the token)

[aakashsharmaa5]

thanks KurtGoogler & Dino for your response.

I have gone through the Github link and the decision tree and have below questions considering End-User Authentication would be required -

1. - In 1A if we go with Open ID Connect pattern and if app exist on Apigee would an open-id app still to be created at IDP (lets say Okta at this point) to support grant type of auth code.

https://github.com/nas-hub/enduser-authentication-for-api-access-via-oidc

Going through the prerequisites and values required for the config file those are available on Okta when i create openid connect app

2. In case of 1A - End-user Authentication for API access via OAuth 2.0 is also given as an option (link below). How will the flow look for this and considerations

https://github.com/nas-hub/Apigee-Enterprise-Security-Design-Patterns/tree/master/IAM-Integration/Id...

3.

For pattern 1B if you can give some pointers for implementation

4 For Patterns that are marked coming soon are they being worked upon and to be available anytime soon?

@Sai Saran Vaidyanathan if you can share the audit trigger demo it will help.

Thanks,

Aakash

[asharma377]

Any update please post on my queries. thanks, Aakash