Utmaningar med villkorlig åtkomst och anspråk

Bakgrund

När du hämtar token utan användarinteraktion kan din app få felmeddelanden när en anspråksutmaning för villkorsstyrd åtkomst, till exempel en MFA-policy, krävs av ett API som du försöker få åtkomst till.

Mönstret för att hantera det här felet är att interaktivt hämta en token med hjälp av MSAL. Interaktiv hämtning av en token anmodar användaren och ger dem möjlighet att uppfylla kraven i den obligatoriska policyn för villkorsstyrd åtkomst.

Note

Det finns vissa principer för villkorlig åtkomst som inte kräver användarinteraktion för att följa principen. I sådana fall rekommenderas det att använda metoden acquire_token_silent för att hantera den anspråksutmaning som returneras och undvika att uppmana användaren till interaktion.

I vissa fall, när du anropar ett API som kräver villkorsstyrd åtkomst, kan du få en anspråksutmaning i felmeddelandet från API:et. Om principen för villkorsstyrd åtkomst till exempel ska ha en hanterad enhet (Intune) blir felet ungefär som AADSTS53000: Enheten måste hanteras för att få åtkomst till den här resursen eller något liknande. I det här fallet kan du skicka med anspråken i anropet för att hämta en token så att användaren uppmanas att uppfylla kraven i rätt policy.

Hantera anspråksutmaning i MSAL-Python

När du anropar ett API som kräver villkorlig åtkomst måste ditt program hantera anspråksfel. Detta visas som ett MSAL-Python felsvar där anspråksegenskapen inte är tom.

För att hantera anspråksutmaningen måste du använda parametern claims_challenge i metoden get_authorization_request_url(). I fall som inte kräver interaktioner måste du använda parametern claims_challenge i acquire_token_silent() metoden och metoden använder uppdateringstoken för att hämta en ny token.

Anspråksutmaning är ett direktiv i rubriken www-authenticate som resursprovidern (t.ex. MS Graph) svarar med, när en åtkomsttoken inte har auktoriserats och en ny åtkomsttoken krävs. Ett exempel på anspråksutmaning från resursprovidern (t.ex. MS Graph) bör se ut så här. Den består av HTTP-statuskod som måste vara 401 och www-authenticate-huvudet som innehåller fälten som nämns ovan.

HTTP 401; Unauthorized 
www-authenticate=Bearer realm="", 
authorization_uri="https://login.microsoftonline.com/common/oauth2/authorize", 
error="insufficient_claims", 
claims="returned_claims"

Klienter måste extrahera anspråken och sedan skicka dem till metoden acquire_token_by_*. Om anspråksvärdet som returneras från resursen är base64-kodat måste det avkodas innan du anropar MSAL. MSAL-acquire_token metoder accepterar anspråk som en json-sträng. Det här är ett exempel på hur anspråk som returneras från resursprovidern kan hanteras med hjälp av auktoriseringskodflöde.

claims_challenge = "claims returned from resource provider"
# if claims parameter is encoded, decode it and use the decoded claims
# decoded_claims_challenge = str(base64.b64decode(claims), "utf-8")

result = None

# Since you were using your previous AT and then met a claims challenge,
# you should've already be in a context with the current signed-in user.
# Here we assume you somehow already have that account,
# or you could possibly get it like this:
accounts = app.get_accounts()
assert accounts
account = accounts[0]

result = app.acquire_token_silent(scope, account=account, claims_challenge=claims_challenge)
if not result:
    # Auth endpoint call for interactive login (you can use auth url helper)
    auth_url = app.get_authorization_request_url(..., claims_challenge=claims_challenge)
    # Make a request to this auth_url to get back authorization_code
    result = app.acquire_token_by_authorization_code(..., claims_challenge=claims_challenge)
  • Den här nya åtkomsttoken kan nu användas i begäran till resursen.
  • Last updated on