Dela via

Skydda program och API:er genom att verifiera anspråk

  • Artikel

Att interagera med token är en viktig del av att skapa program för att auktorisera användare. I enlighet med Nolltillit-principen för åtkomst med minst privilegier är det viktigt att program validerar värdena för vissa anspråk som finns i åtkomsttoken när de utför auktorisering.

Med anspråksbaserad auktorisering kan program se till att token innehåller rätt värden för saker som klientorganisation, ämne och aktör som finns i token. Med detta sagt kan anspråksbaserad auktorisering verka komplex med tanke på de olika metoderna att använda och scenarier att hålla reda på. Den här artikeln syftar till att förenkla den anspråksbaserade auktoriseringsprocessen så att du kan se till att dina program följer de säkraste metoderna.

För att säkerställa att din auktoriseringslogik är säker måste du verifiera följande information i anspråk:

  • Lämplig målgrupp anges för token.
  • Klientorganisations-ID:t för token matchar ID:t för klientorganisationen där data lagras.
  • Ämnet för token är lämpligt.
  • Aktören (klientappen) är auktoriserad.

Kommentar

Åtkomsttoken verifieras endast i de webb-API:er som de hämtades av en klient för. Klienten bör inte verifiera åtkomsttoken.

Mer information om anspråken som nämns i den här artikeln finns i Microsofts identitetsplattform åtkomsttoken.

Verifiera målgruppen

Anspråket aud identifierar den avsedda målgruppen för token. Innan du verifierar anspråk måste du alltid kontrollera att värdet för anspråket aud som finns i åtkomsttoken matchar webb-API:et. Värdet kan bero på hur klienten begärde token. Målgruppen i åtkomsttoken beror på slutpunkten:

  • För v2.0-token är målgruppen klient-ID för webb-API:et. Det är ett GUID.
  • För v1.0-token är målgruppen en av appID-URI:erna som deklareras i webb-API:et som verifierar token. Till exempel api://{ApplicationID}, eller ett unikt namn som börjar med ett domännamn (om domännamnet är associerat med en klientorganisation).

Mer information om appID-URI för ett program finns i Program-ID URI.

Verifiera klientorganisationen

Kontrollera alltid att tid i en token matchar klientorganisations-ID:t som används för att lagra data med programmet. När information lagras för ett program i kontexten för en klientorganisation bör den endast nås igen senare i samma klientorganisation. Tillåt aldrig att data i en klientorganisation nås från en annan klientorganisation.

Validering av klientorganisationen är bara det första steget, och kontroller av ämne och aktör som beskrivs i den här artikeln krävs fortfarande. Om din avsikt är att auktorisera alla användare i en klientorganisation rekommenderar vi starkt att du uttryckligen lägger till dessa användare i en grupp och auktoriserar baserat på gruppen. Om du till exempel bara kontrollerar klientorganisations-ID:t och förekomsten av ett oid anspråk kan ditt API oavsiktligt auktorisera alla tjänsthuvudnamn i klientorganisationen utöver användarna.

Verifiera ämnet

Kontrollera om tokenämnet, till exempel användaren (eller själva programmet för en apptoken), har behörighet.

Du kan antingen söka efter specifika sub eller oid anspråk.

Eller:

Du kan kontrollera att ämnet tillhör en lämplig roll eller grupp med anspråken roles, scp, groups, wids . Du kan till exempel använda de oföränderliga anspråksvärdena tid och oid som en kombinerad nyckel för programdata och avgöra om en användare ska beviljas åtkomst.

Anspråken roles, groups eller wids kan också användas för att avgöra om ämnet har behörighet att utföra en åtgärd, även om de inte är en fullständig lista över alla sätt som ett ämne kan beviljas behörigheter på. En administratör kan till exempel ha behörighet att skriva till ett API, men inte en normal användare, eller så kan användaren vara i en grupp som kan utföra vissa åtgärder. Anspråket wid representerar de klientomfattande roller som tilldelats användaren från de roller som finns i de inbyggda Rollerna i Microsoft Entra. Mer information finns i Inbyggda roller i Microsoft Entra.

Varning

Använd aldrig anspråk som email, preferred_username eller unique_name för att lagra eller avgöra om användaren i en åtkomsttoken ska ha åtkomst till data. Dessa anspråk är inte unika och kan styras av klientadministratörer eller ibland användare, vilket gör dem olämpliga för auktoriseringsbeslut. De kan bara användas i visningssyfte. Använd inte heller anspråket upn för auktorisering. Även om UPN är unikt ändras det ofta under livslängden för ett användarhuvudnamn, vilket gör det otillförlitligt för auktorisering.

Verifiera aktören

Ett klientprogram som agerar för en användares räkning (kallas aktören) måste också vara auktoriserat. Använd anspråket (omfånget scp ) för att verifiera att programmet har behörighet att utföra en åtgärd. Behörigheterna i scp bör begränsas till vad användaren faktiskt behöver och följa principerna för lägsta behörighet.

Det finns dock förekomster där scp inte finns i token. Du bör söka efter frånvaron av anspråket scp för följande scenarier:

  • Daemon-appar/endast appbehörighet
  • ID-token

Mer information om omfång och behörigheter finns i Omfång och behörigheter i Microsofts identitetsplattform.

Kommentar

Ett program kan hantera endast apptoken (begäranden från program utan användare, till exempel daemonappar) och vill auktorisera ett specifikt program mellan flera klienter i stället för enskilda tjänsthuvudnamns-ID:t. I så fall kan anspråket appid (för v1.0-token) eller anspråket azp (för v2.0-token) användas för ämnesauktorisering. När du använder dessa anspråk måste programmet dock se till att token har utfärdats direkt för programmet genom att verifiera det valfria anspråket idtyp . Endast token av typen app kan auktoriseras på det här sättet, eftersom delegerade användartoken potentiellt kan hämtas av andra entiteter än programmet.

Nästa steg