How to Choose between APIM <get-authorization-context..> & <validate-azure-ad-token>?

Question

How to Choose between APIM <get-authorization-context..> & <validate-azure-ad-token>?

Siegfried Heintze 1,906

Previously ([https://learn.microsoft.com/en-us/answers/questions/1132295/azure-api-management-(apim)-restriction-policies-v) I learned that both <validate-jwt> and <validate-azure-ad-token> can be used to deny a user access to an APIM.

Since then I've been studying [https://learn.microsoft.com/en-us/azure/api-management/get-authorization-context-policy#examples and [https://learn.microsoft.com/en-us/azure/api-management/authorizations-how-to and I see here ([https://learn.microsoft.com/en-us/azure/api-management/api-management-policies#access-restriction-policies) that like <validate-jwt> (and therefor <validate-azure-ad-token>), <get-authorization-context> can be used to implement "Access Restriction Policies".

Is this correct?
It says "In this article, you learn how to create an authorization (preview) in API Management and call a GitHub API that requires an authorization token". Does this mean that this technique only allows me call functions implemented by identity providers like Google, Github and Facebook and if I wanted to use this technique to call my azure function, I would have to be an identity provider provider like Google, Github or Facebook?

Thanks

Siegfried

Accepted answer

2 additional answers

Your answer

Answer 1

Good but the point is how is this error thrown? Is that a 401?

Or is any kind of error regarding the policy and therefore I would have to know this error?

When I use the trace to debug the access token renewal I get no error message except for a 401 in the end which does not tell me if it was caused by the policy or sent by the backend itself, did ou get it?

The documentation and examples should have this shown.

Anyway, I'm using client credentials, so I won't have a refresh token URL.

OK for that. I get that I have to keep an eye on the error message. But if I don't know what kind of message is that, I cannot handle it.

So far I'm just having this:

get-authorization-context (6.499 ms)
"Using cache 'internal'."

get-authorization-context (595.598 ms)
{
    "message": "Obtaining managed identity token using clientId:f0da2222-67f1-4229-2202-eb2221369287 AAD Authority:https://login.windows.net/82222226-0477-4390-b86e-22222222222 for https://apihub.azure.com audience succeeded.",
    "errorResponse": null
}

get-authorization-context (621.931 ms)
{
    "message": "Obtaining managed identity token using clientId:f011113e-67f1-4b79-8d02-11111369287 AAD Authority:https://login.windows.net/82222226-0477-4390-b86e-22222222222 for https://azure-api.net/authorization-manager audience succeeded.",
    "errorResponse": null
}

get-authorization-context (5.845 ms)
{
    "message": "Sending request to authorization provider gateway.",
    "request": {
        "apimServiceName": "3333y",
        "providerId": "outsystems-oauth2",
        "authorizationId": "outsystems-oauth2",
        "identityType": "managed",
        "identityMetadata": "{ objectId: 441d34344500494, tenantId: 809f94a63434344353453a7 }",
        "correlationId": "9ad2432345d2"
    }
}

get-authorization-context (2,255.140 ms)
"Using cache 'internal'."

get-authorization-context (9.969 ms)
"Authorization context was added to 'auth-context' variable."

set-header (5.827 ms)
{
    "message": "Expression was successfully evaluated.",
    "expression": "((Authorization)context.Variables.GetValueOrDefault(\"auth-context\"))?.AccessToken",
    "value": "eyJhbGciOiJIUzI1NiIs-.-Njc1MTg5Mz-TR9.-P9Vw"
}

set-header (0.014 ms)
{
    "message": "Specified value was assigned to the header (see below).",
    "header": {
        "name": "Authorization",
        "value": "eyJhbGciOiJIUzI1NiIs-.-Njc1MTg5Mz-TR9.-P9Vw"
    }
}

Which means I'm still getting a token, invalid though......

Answer 2

JananiRamesh-MSFT 29,236

Hi @Siegfried Heintze Thanks for reaching out. Yes get-authorization-context can also be used to implement access restriction policies.

The <get-authorization-context> policy is used to extract the authorization context from an incoming request and make it available to the other policies in APIM. It is typically used in conjunction with other policies, such as <validate-jwt> and <validate-azure-ad-token>, to implement access restriction policies.

The example in the doc demonstrates how to use the <get-authorization-context> policy to call a GitHub API that requires an authorization token. However, this can be used to call any API that requires an authorization token, regardless of whether the API is provided by an identity provider like Google, GitHub, or Facebook, or by a custom service like an Azure function.

Do let me know if you have any queries.

Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community looking for help on similar topics.

Siegfried Heintze 1,906 Reputation points

2023-01-16T17:18:31.14+00:00
Oh! That is very interesting. I did not expect that answer! Thank you!

So here is a nice tutorial (https://learn.microsoft.com/en-us/azure/api-management/howto-protect-backend-frontend-azure-ad-b2c) for using validate-jwt.

Is this an example of documentation that needs to be updated to use validate-azure-ad-token instead of validate-jwt?

Please explain when I would use both get-authorization-context and validate-jwt or validate-azure-ad-token.

Please point me to an example how I might use both get-authorization-context and validate-jwt or validate-azure-ad-token. I've been bing searching and I cannot find such an example.

Thanks

Siegfried
JananiRamesh-MSFT 29,236 Reputation points

2023-01-18T18:04:15.3833333+00:00

Hi @Siegfried Heintze Thanks for getting back,

Is this an example of documentation that needs to be updated to use validate-azure-ad-token instead of validate-jwt?

Yes, As mentioned earlier Docs are lagging, we expect customers to use validate-aad-token with aad tokens and validate-jwt with any other jwt.

get-authorization-context policy fetches and stores authorization and refresh tokens from the configured authorization provider which can be stored in a variable that can be later used in the policy flow.

validate-jwt and validate-azure-ad-token a policy used to validate JSON Web Tokens (JWT) and Azure Active Directory (AAD) tokens passed in the request. It verifies that the token is valid, has not expired, and has been issued by a trusted issuer.

please refer sample flow of policy below:

In the get-authorization-context policy, you would extract the token and set it as a variable in the context.

Next, in the validate-jwt policy/validate-azure-ad-token, you would use that variable to validate the token against your configured issuer and audience.

If the token is valid the request will be forwarded to the backend else, it would return an error.

I hope this clarifies!

Do let me know incase of further queries.

Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community looking for help on similar topics.
Siegfried Heintze 1,906 Reputation points

2023-01-20T17:45:26.5733333+00:00

Thanks! That is helpful!

Please explain how APIM normally works when only using validate-jwt and validate-azure-ad-token (and not get-authorization-context).

I believe the way it works is that the client app supplies a JWT (a bearer token from azure-AD for example) with each call to the REST API via APIM and APIM validates the JWT using validate-jwt or validate-azure-ad-token for every call. Is this correct?

So I might use get-authorization-context because the client only sends the JWT once and thereafter APIM could grab the JWT stored in the variable and pass that on to the backend? Is that the use-case you are suggestion?

Thanks

Siegfried
Gustavo Guerreiro Basilio Costa 80 Reputation points

2023-02-02T12:26:14.6066667+00:00

I implemented <get-authorization-context> in my inbound policies in order to get authorization token for my backend endpoint. At first the policy applied worked just fine but in the next day, it was not working anymore. I tried debugging the token and understood that it was expired.

Wouldn't <get-authorization-context> refresh the token if its expired? How do I do this?
MuthuKumaranMurugaachari-MSFT 22,416 Reputation points

2023-02-02T17:18:25.0566667+00:00
@Gustavo Guerreiro Basilio Costa There are two process flows involved here as explained in doc.

Process flow for creating authorizations

involves creating authorization, then fetch access and refresh token.

Process flow for runtime

if access token is expired and refresh token is valid, then APIM will new access token and refresh token.

But if refresh token is expired, then it will throw error as described in doc: https://learn.microsoft.com/en-us/azure/api-management/authorizations-overview#when-are-the-access-tokens-refreshed and need the user to reauthorize.

If you have any other questions, feel free to post a new thread.

Answer 3

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Share via

How to Choose between APIM <get-authorization-context..> & <validate-azure-ad-token>?

2 additional answers

Your answer