Client Credentials provided by Azure AD vs Apigee

[asharma377]

hi

We are looking for client credentials as the grant type for one of the usecase for server to server communication.

We have Azure AD as Identity provider -

1. Azure AD provides provision to create apps and associate and thus also has client credentials at their end

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow

I can obtain access token by calling - http://login.microsoftonline.com/aa143a9f-4be7-4c86-a764-041a9cba5e8d/oauth2/v2.0/token

with client id,secret, token,scope being passed as form-parameters

I can obtain a token and then pass it to APIGEE and check with VerifyJWT whether it is a valid token or not. I will need public keys of Azure AD to perform the check that i can get

In other words token generation happened outside of Apigee already and I am validating it.

this post does talk about it - https://community.apigee.com/questions/59841/validating-jwt-generated-from-azure-ad.html

2. Other way is we create app in APIGEE and then use a service callout as prescribed in the link below to make a call to AD

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

I will have to maintain clientid, secret of azure ad in Apigee, and then make the call to retrieve the token.

What is a better option and also keeping it consistent for other granttypes that we will support with AzureAD integration

Also, for (2) Should i pass the azure ad token back to client or exchange it for another token generated in Apigee. What are the pros and cons of each, and factors to decide.

Should this token be cached for better performance using cache policy

thanks,

Aakash

[#2]

We have used both scenarios.

In our old implementation we were using option 2 but not as service callout. We used external oauth, so that the AD token will be stored in apigee and get validated. Our consumer didn't like to create two token one for AD and one for Apigee.

The first scenario is our new security standard. We do use IDP api call to get the token and then the same token is used to do service call, which get validated in apigee as JWT validation against IDP public key stored in encrypted KVM. This approach doesn't need to validate again in AD. So, the api latency is better. Also we get caims options as well as source and audience which can be validated to ensure the correct consumer is requesting. Credentials theft probe is there as we do check the client app and the audience in the token are same or not.

So, I would suggest to go for the option 1.

[asharma377]

thanks Priyadarshi for your reply. Couple of questions I have on your inputs -

1. "We do use IDP api call to get the token and then the same token is used to do service call"

AS: Any specific reason that it is a direct api call to IDP and not routed via Apigee to get the token. In client credentials, as generate token too we can make the call and cache that token too to avoid interaction with IDP till it expires.

2.

"Credentials theft probe is there as we do check the client app and the audience in the token are same or not"

AS: I understand you are using verifyapi key then to validate the client id and JWT passed by user as Bearer token gets validated as second step. So it is not client credentials at apigee side.

3. In Azure AD, did you create an app with client id and secret and are using grant_type client_credentials and url below to obtain the token or any other way

http://login.microsoftonline.com/xxx/oauth2/v2.0/token

thanks!

Aakash

[#4 · Accepted solution]

Hi,

Find below notes.

1. "We do use IDP api call to get the token and then the same token is used to do service call"

AS: Any specific reason that it is a direct api call to IDP and not routed via Apigee to get the token. In client credentials, as generate token too we can make the call and cache that token too to avoid interaction with IDP till it expires.

>> This is a 2 legged format. Normally the user should have a valid token to access one api. If we will put the same in one proxy flow it will get new token every time and then validate in the same proxy flow. Think like a token is reusable in that case we shouldn't hit the IDP every time. Another thing the api latency will increase. A lot many factors will come to the picture if we calculate. JWT and oauth 2.0 follow this similar flow.

2.

"Credentials theft probe is there as we do check the client app and the audience in the token are same or not"

AS: I understand you are using verifyapi key then to validate the client id and JWT passed by user as Bearer token gets validated as second step. So it is not client credentials at apigee side.

>> Client credentials is for trust applications. Here I say is first get the token from IDP. The token will have the claims, audience, issuer and things. In the token validation, once token signature is verified all these will be available in the flow. Then you can cross verify the audience and the service caller are same or not. Other validations also can be done using javascript. JWT token can be used as oauth token. IDP supports token creation as client_credentails type. We use ISAM IDP. the first request gives us a token and its client credentials type. Then we use that one for service and it gets JWT validated.

3. In Azure AD, did you create an app with client id and secret and are using grant_type client_credentials and url below to obtain the token or any other way

http://login.microsoftonline.com/xxx/oauth2/v2.0/token

[asharma377]

thank you !! Some points if you can clarify -

1. "This is a 2 legged format. Normally the user should have a valid token to access one api. If we will put the same in one proxy flow it will get new token every time and then validate in the same proxy flow"

AS: I was asking if the token that app get from Azure AD should this be a direct call or should it route through API Gateway itself.

2. AS: Token Issued by by IDP this is the identity token i guess? Most of the articles for oauth says identity token should be exchanged for access token to make API calls. The proteced API/resources are at APIGEE but the token is issued by IDP. Is it correct to use the token to access authorized resources at API Gateway

3. A client app using it for server-server communication may cache this token. What is the time period of such tokens? Any security implications for the same. Also, how do you handle the expiry of token, refresh token.

many thanks!!

[#6]

As you spet it's two legged oauth, do first api call to get the access token. If the token is valid then you need not to this call and use the same token.

The secont call will be used for the token validation and service call.

You can use external oauth in Apigee, so that Apigee will validate the token, else you need to do using service callout.

[asharma377]

thank you priyadarshi!