Can we generate Unique Aceess token for different oAuth flows in Apigee v 4.17.09.00

Hello All,

As now in my organization, we have a different flow that generates the Apigee token, such as below and makes a call to our API proxies.

1. Internal SSO flow using grant type oAuth code to generate Apigee tokens.

2. Login with Graph 365: In this flow, a user will use Graph SDK/lib/code to use graph 365 login, our flow will only provide APIGEE access token to call other APIs. We are providing provision to use Internal APIs with graph 365 login.

3. Login to Azure 365: In this flow, a user will use Azure SDK/lib/code to use azure 365 logins, our flow will only provide APIGEE access token to call other APIs.

Above flows are set to different product and call respective API associated with that Product.

Now the scenario is that from Developer portal if someone creates an APP and use above Product which may contain 3 different flow as mention above then he needs to type his credential 3 times which may impact the flow, as here credentials are same, as he is using organization AD account.

Is there any generic flow we can set that if from the developer portal he uses any product that will generate the unique token and with the help of that unique token he can access all the APIs from the product mention on the portal.

@Dino @Anil Sagar @Mike Dunker @Mudit Kumar @birute@google.com @Siddharth Barahalikar or someone from the community, please, can you suggest some solution on this would be really helpful.

Solved Solved
0 3 396
1 ACCEPTED SOLUTION

we want to achive the same scenario that only one-time user needs to enter his credentials and on basis of that the token should be generated and using that token we will be able to call all internal services (such as Organization services ) and external services ( such as O365, Azure services) through APIs.

Hmm, ok that's a pretty clear question!

Yes, I think you can accomplish what you want.

Oauth supports several flows that support user authentication. One is called "password grant" and the other is "authorization code" flow. Both are described elsewhere in some detail.

Apigee Edge can issue tokens to a user via either of those grant types. Apigee Edge can then verify the token at runtime, when it is presented in a REST request. It's up to you (the person configuring Apigee Edge) to specify:

  • which permissions or scopes ought to be associated to the token when issued
  • which permissions or scopes are required on the token to invoke any particular request (O365, or other)

Here's a screencast demonstrating issuing tokens in Apigee Edge via the Password Grant, and then using those tokens in subsequent requests. 12 minutes. This is basically exacrtly what you're asking for. In this demonstration, there is no "backend service" - but that's an easy detail to add. Just append the call to the backend system (in Apigee Edge this is done via a "Target Endpoint") after you verify the token and its scopes.

View solution in original post

3 REPLIES 3

Hi

I read your question, and I'm not clear on the problem.

I don't understand this statement.

Above flows are set to different product and call respective API associated with that Product.

Token issuing "flows" aren't "set to" products. Token issuance flows issue tokens, and that's it. There's no "setting".

The product wraps one or more API proxies (usually). But those API Proxies are not (should not be) the proxies that issue tokens. In fact this is a confusing part of the Apigee Edge model. Some proxies MUST be within an API product, and some proxies - specifically token issuing proxies - should almost never be within any API Product.

Given this information, if you could clarify what you mean by "Above flows are set to different product and call respective API associated with that Product.", that might help me.

I also don't understand this:

Now the scenario is that from Developer portal if someone creates an APP and use above Product which may contain 3 different flow

Which product? You said "Above product" but you didn't clearly describe which API Products are in the mix.

And also I'm not sure how any of the information applies to the summary you used, in which you said you'd like to create a "unique oauth token". Every token is unique, so ... I'm not clear on what you mean by that phrase.

I'm sorry if it seems I am dull. Trying to understand but I just don't get it.

Maybe all of that is irrelevant. Your main question seems to be:

Is there any generic flow we can set that if from the developer portal he uses any product that will generate the unique token

No, if I understand what you are asking, I don't think it is possible. If you want to allow developers to use the devportal to actually invoke the APIs exposed by your products, then you need to use the proper authentication. There must be no way to "bypass" the authentication you have set up.

But it's possible I don't understand.

Hello, @Dino-at-Google

As you mention that,
I read your question, and I'm not clear on the problem.
To get what our problem is you can check out here SAML Overview vedio in this 10min video the last section how he mentions BIG-IP act as an Identity provider and rest all the different services which he is trying to access is done with the same credentials. Which means we want to achive the same scenario that only one-time user needs to enter his credentials and on basis of that the token should be generated and using that token we will be able to call all internal services (such as Organization services ) and external services ( such as O365, Azure services) through APIs.


A question here is, can we achieve above use-case using Apigee, if yes then whats the optimal way to do this.?

we want to achive the same scenario that only one-time user needs to enter his credentials and on basis of that the token should be generated and using that token we will be able to call all internal services (such as Organization services ) and external services ( such as O365, Azure services) through APIs.

Hmm, ok that's a pretty clear question!

Yes, I think you can accomplish what you want.

Oauth supports several flows that support user authentication. One is called "password grant" and the other is "authorization code" flow. Both are described elsewhere in some detail.

Apigee Edge can issue tokens to a user via either of those grant types. Apigee Edge can then verify the token at runtime, when it is presented in a REST request. It's up to you (the person configuring Apigee Edge) to specify:

  • which permissions or scopes ought to be associated to the token when issued
  • which permissions or scopes are required on the token to invoke any particular request (O365, or other)

Here's a screencast demonstrating issuing tokens in Apigee Edge via the Password Grant, and then using those tokens in subsequent requests. 12 minutes. This is basically exacrtly what you're asking for. In this demonstration, there is no "backend service" - but that's an easy detail to add. Just append the call to the backend system (in Apigee Edge this is done via a "Target Endpoint") after you verify the token and its scopes.