Solved: Client Credentials provided by Azure AD vs Apigee - Page 2

asharma377 · 11-18-2020 05:11 PM

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

Report Inappropriate Content

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

View solution in original post