AD FS OpenID Connect/OAuth-flöden och programscenarier

Gäller för Active Directory Federation Services (AD FS) 2019 och senare

Implicit beviljandeflöde

För ensidesprogram (AngularJS, Ember.js, React.jsoch så vidare) stöder AD FS implicit beviljandeflöde för OAuth 2.0. Det implicita flödet beskrivs i OAuth 2.0-specifikationen. Den främsta fördelen är att appen kan hämta token från AD FS utan att utföra ett utbyte av autentiseringsuppgifter för serverservern. Med det här flödet kan appen logga in på användaren, underhålla sessionen och hämta token till andra webb-API:er i klientens JavaScript-kod. Det finns några viktiga säkerhetsöverväganden att tänka på när du använder det implicita flödet, särskilt kring klienten.

Om du vill använda implicit flöde och AD FS för att lägga till autentisering i JavaScript-appen följer du de allmänna stegen i följande avsnitt.

Protokolldiagram

Följande diagram visar hur hela det implicita inloggningsflödet ser ut. Avsnitten som följer beskriver varje steg mer detaljerat.

Begära en ID-token och åtkomsttoken

Om du först vill logga in användaren i din app kan du skicka en OpenID Connect-autentiseringsbegäran och hämta en id_token- och åtkomsttoken från AD FS-slutpunkten.

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345

Nu uppmanas användaren att ange sina autentiseringsuppgifter och slutföra autentiseringen. När användaren har autentiserats returnerar AD FS-auktoriseringsslutpunkten ett svar till din app på den angivna redirect_uri med hjälp av den metod som anges i parametern response_mode.

Lyckat svar

Ett lyckat svar, när response_mode=fragment and response_type=id_token+token det används, ser ut så här:

// Line breaks for legibility only

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZEstZnl0aEV...
&token_type=Bearer
&expires_in=3599
&scope=openid
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZstZnl0aEV1Q...
&state=12345

Uppdatera tokenar

Den implicita tilldelningen ger inte uppdateringstokener. Både id_tokens och access_tokens upphör att gälla efter en kort tidsperiod, så din app måste vara beredd att uppdatera dessa token regelbundet. Om du vill uppdatera någon av tokentyperna kan du utföra samma dolda iframe-begäran som i föregående avsnitt med hjälp av parametern prompt=none för att styra identitetsplattformens beteende. Om du vill ta emot en ny id_token ska du använda response_type=id_token.

Beviljandeflöde för auktoriseringskod

Du kan använda OAuth 2.0-auktoriseringskoden i webbappar för att få åtkomst till skyddade resurser som webb-API:er. OAuth 2.0-auktoriseringskodflödet beskrivs i avsnitt 4.1 i OAuth 2.0-specifikationen. Den används för att utföra autentisering och auktorisering i de flesta apptyper, inklusive webbappar och inbyggda appar. Flödet gör det möjligt för appar att på ett säkert sätt hämta access_tokens som kan användas för att komma åt resurser som litar på AD FS.

Protokolldiagram

På hög nivå ser autentiseringsflödet för ett internt program ut ungefär så här:

Begära en auktoriseringskod

Auktoriseringskodflödet börjar med att klienten dirigerar användaren till slutpunkten /authorize. I den här begäran anger klienten de behörigheter som krävs för att hämta från användaren:

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&resource=https://webapi.com/
&scope=openid
&state=12345

Nu uppmanas användaren att ange sina autentiseringsuppgifter och slutföra autentiseringen. När användaren har autentiserats returnerar AD FS ett svar till din app på angiven redirect_uri, med hjälp av den metod som anges i parametern response_mode .

Lyckat svar

Ett lyckat svar, när response_mode=query används, ser ut så här:

GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345

Begära en åtkomsttoken

Nu när du har skaffat en authorization_code och har fått tillstånd från användaren kan du lösa in koden för en access_token till önskad resurs. Lös in koden genom att skicka en POST-begäran till slutpunkten /token:

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com/
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for confidential clients (web apps)

Lyckat svar

Ett lyckat tokensvar ser ut så här:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Använda åtkomsttoken

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Uppdatera flödet för tokenbidrag

Access_tokens är kortvariga och du måste uppdatera dem när de upphör att gälla för att fortsätta komma åt resurser. Du kan göra det genom att skicka en annan POST-begäran till /token slutpunkten, den här gången genom att ange refresh_token i stället för koden. Uppdateringstoken är giltiga för alla behörigheter som klienten redan har tagit emot åtkomsttoken för.

Uppdateringstoken har inte angivna livslängder. Normalt är livslängden för uppdateringstoken relativt lång. I vissa fall upphör dock uppdateringstoken att gälla, återkallas eller saknar tillräcklig behörighet för den önskade åtgärden. Programmet måste förvänta sig och hantera fel som returneras av slutpunkten för tokenutfärdning korrekt.

Även om uppdateringstoken inte återkallas när de används för att hämta nya åtkomsttoken förväntas du ta bort den gamla uppdateringstoken. OAuth 2.0-specifikationen säger: "Auktoriseringsservern kan utfärda en ny uppdateringstoken, i vilket fall klienten MÅSTE ta bort den gamla uppdateringstoken och ersätta den med den nya uppdateringstoken. Auktoriseringsservern kan återkalla den gamla uppdateringstoken efter att ha utfärdat en ny uppdateringstoken till klienten." AD FS utfärdar uppdateringstoken när den nya uppdateringstokens livslängd är längre än tidigare livslängd för uppdateringstoken. Mer information om livslängden för AD FS-uppdateringstoken finns i inställningarna för enkel inloggning med AD FS.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for confidential clients (web apps)

Lyckat svar

Ett lyckat tokensvar ser ut så här:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Stöd för Proof Key for Code Exchange (PKCE) för OAuth

Offentliga OAuth-klienter som använder auktoriseringskodflödet är sårbara för avlyssningsattacker på auktoriseringskoder, enligt beskrivningen i RFC 7636. För att undvika dessa attacker stöder AD FS från och med Windows Server 2019 proof key for code exchange (PKCE) för OAuth-auktoriseringskodens beviljandeflöde.

PKCE-supportspecifikationen lägger till fler parametrar i begäranden om OAuth 2.0-auktorisering och åtkomsttoken. Följande diagram visar en översikt över PKCE-processen när en klient kontaktar AD FS i Windows Server 2019.

I avsnittet A skapar och registrerar klienten en hemlighet med namnet code_verifier och härleder en transformerad version av hemligheten med namnet t(code_verifier), även kallad code_challenge. Klienten skickar sedan hemligheten i OAuth 2.0-auktoriseringsbegäran tillsammans med t_m transformeringsmetoden.

I avsnittet B svarar auktoriseringsslutpunkten som vanligt, men registrerar t(code_verifier) hemligheten och transformeringsmetoden.

I avsnittet C skickar klienten auktoriseringskoden i begäran om åtkomsttoken som vanligt, men innehåller hemligheten code_verifier som genereras i avsnitt A.

I avsnittet D omvandlar AD FS hemligheten code_verifieroch jämför den med hemligheten t(code_verifier) från avsnitt B. Om deras värden inte är lika med nekar AD FS åtkomst.

Så här väljer du flera autentiseringsprovidrar för samma regelprincip i Windows Server 2019

AD FS har redan stöd för att utlösa extra autentisering baserat på en anspråksregelprincip (RP). Du kan ange dessa principer för en viss RP eller på global nivå. Du kan ange en extra autentiseringsprincip för en viss RP genom att öppna PowerShell som administratör och köra cmdleten Set-AdfsRelyingPartyTrust genom att antingen skicka parametern AdditionalAuthenticationRules eller AdditionalAuthenticationRulesFile . Om du vill ange det globalt kan en administratör använda cmdleten Set-AdfsAdditionalAuthenticationRule. Genom att ange extra principer kan du använda mer än en autentiseringsprovider för samma program.

Anspråksregler ger möjlighet att välja autentiseringsprovidern för ytterligare autentisering, vilket visar sig vara fördelaktigt i situationer där kunder byter mellan leverantörer eller kräver en distinkt leverantör för vissa program. Från och med Windows Server 2019 kan du använda anspråksregler för att bestämma vilken annan autentiseringsprovider som ska anropas för extra autentisering. Den här funktionen är användbar i två scenarier:

• Användarna övergår från en autentiseringsprovider till en annan. När du registrerar användare till en nyare autentiseringsprovider kan de använda grupper för att styra vilken extra autentiseringsprovider som tjänsten använder.

• Användare behöver en specifik extra autentiseringsprovider för vissa program men måste också använda en annan metod för andra program.

Du kan konfigurera de här inställningarna genom att köra följande kommando från andra autentiseringsprinciper:

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );' 

Om du vill konfigurera denna regel måste du utfärda anspråket http://schemas.microsoft.com/claims/authnmethodsproviders från andra autentiseringspolicyer. Värdet för det här anspråket ska vara variabeln Namn för autentiseringsprovidern.

Du kan också ändra den här regelkonfigurationen för att hjälpa användare att övergå från en autentiseringsprovider till en annan. Anta till exempel att du vill ändra en grupp som du hanterar för att använda Microsoft Entra multifaktorautentisering (MFA) och en grupp för att använda certifikat som en extra autentiseringsprovider.

Om du vill spåra hur många personer som registrerar sig för MFA och certifikatautentisering kan du köra ett kommando som det här, med de värden som ersätts med värden som är relevanta för din organisation:

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’ 

Sedan kan du ange det första programmet, kallat AppA, för att använda MFA som en extra autentiseringsprovider genom att köra det här kommandot:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

Slutligen kan du ange den andra appen, kallad AppB, för att använda certifikat som en extra autentiseringsprovider genom att köra det här kommandot:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

Administratörer kan också skapa regler för att tillåta mer än en extra autentiseringsprovider. I det här fallet visar AD FS de utfärdade autentiseringsmetodprovidrar och en användare kan välja någon av dem. Om du vill tillåta flera extra autentiseringsprovidrar bör de utfärda flera anspråk med hjälp av värdet http://schemas.microsoft.com/claims/authnmethodsproviders.

Om anspråksutvärderingen inte returnerar någon av autentiseringsprovidrar rullar AD FS tillbaka och visar en lista som visar alla extra autentiseringsproviders som konfigurerats av administratören på AD FS. Användaren måste sedan manuellt välja lämplig autentiseringsprovider.

Om din föredragna autentiseringsprovider inte finns med i listan kan du köra följande cmdlet för att visa alla leverantörer som stöds:

(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

Värdet som du använder för anspråket http://schemas.microsoft.com/claims/authnmethodsproviders ska vara ett av providernamnen som returneras av listan över leverantörer som AD FS returnerade.

AD FS stöder inte att utlösa en specifik extra autentiseringsleverantör när RP använder -principer för åtkomstkontroll i AD FS Windows Server 2016. När du flyttar ett program från en åtkomstkontrollprincip kopierar AD FS motsvarande princip från Åtkomstkontrollprincip till AdditionalAuthenticationRules och IssuanceAuthorizationRules. Om en administratör vill använda en specifik autentiseringsprovider bör de sluta använda principen för åtkomstkontroll och i stället ändra AdditionalAuthenticationRules.

On-Behalf-Of flow

OAuth 2.0 On-Behalf-Of flow (OBO) hanterar användningsfallet där ett program anropar en tjänst/webb-API, som i sin tur måste anropa en annan tjänst/webb-API. Tanken är att sprida den delegerade användaridentiteten och behörigheterna via begärandekedjan. För att mellannivåtjänsten ska kunna göra autentiserade begäranden till den underordnade tjänsten måste den skydda en åtkomsttoken från AD FS för användarens räkning.

Protokolldiagram

Anta att en användare autentiseras i ett program med hjälp av OAuth 2.0-auktoriseringskodens beviljandeflöde som beskrivs i föregående avsnitt. I det här läget har programmet en åtkomsttoken för API A (token A) med användarens anspråk och medgivande för att få åtkomst till webb-API:et på mellannivå (API A). Säkerställ att klienten begär användarimitation urval i token. Api A måste nu göra en autentiserad begäran till det underordnade webb-API:et (API B).

Stegen som följer utgör OBO-flödet och förklaras med hjälp av följande diagram.

1. Klientprogrammet skickar en begäran till API A med token A. (När du konfigurerar OBO-flödet i AD FS kontrollerar du att omfånget user_impersonation är valt och att klienterna begär user_impersonation omfång i begäran.)
2. API A autentiserar till AD FS-tokenutfärdarslutpunkten och begär en token för åtkomst till API B. (När du konfigurerar det här flödet i AD FS kontrollerar du att API A också är registrerat som ett serverprogram med ett klient-ID som har samma värde som resurs-ID:t i API A.)
3. AD FS-tokenutfärdarslutpunkten validerar API A:s autentiseringsuppgifter med token A och utfärdar åtkomsttoken för API B (token B).
4. Token B anges i auktoriseringshuvudet för begäran till API B.
5. Data från den skyddade resursen returneras av API B.

Begäran om tjänst-till-tjänst-åtkomsttoken

Om du vill begära en åtkomsttoken skapar du en HTTP POST till AD FS-tokenslutpunkten med parametrarna som beskrivs i följande avsnitt.

Första fallet: Åtkomsttokenbegäran med en delad hemlighet

För en delad hemlighet innehåller en begäran om tjänst-till-tjänst-åtkomsttoken följande parametrar:

Example

Följande HTTP POST begär en åtkomsttoken och en uppdateringstoken.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=https://webapi.com/
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIm…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope=openid

Andra fallet: Begäran om åtkomsttoken med ett certifikat

En tjänst-till-tjänst-åtkomsttokenbegäran med ett certifikat innehåller följande parametrar:

Observera att parametrarna är nästan desamma. Det här exemplet liknar begäran av delad hemlighet, förutom att parametern client_secret ersätts av två parametrar: client_assertion_type och client_assertion.

Example

Följande HTTP POST begär en åtkomsttoken för webb-API:et med ett certifikat.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id= https://webapi.com/
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNS…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope= openid

Åtkomsttokensvar för tjänst-till-tjänst

Ett lyckat svar är ett JSON OAuth 2.0-svar som har följande parametrar.

Exempel på lyckat svar

I följande exempel visas ett lyckat svar på en begäran om en åtkomsttoken för webb-API:et.

{
  "token_type": "Bearer",
  "scope": openid,
  "expires_in": 3269,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1t"
  "id_token": "aWRfdG9rZW49ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOa"
  "refresh_token": "OAQABAAAAAABnfiG…"
  "refresh_token_expires_in": 28800,
}

Använda åtkomsttoken för att komma åt den skyddade resursen

Nu kan mellannivåtjänsten använda den token som hämtades i föregående svarsexempel för att göra autentiserade begäranden till det underordnade webb-API:et. Ange token i auktoriseringshuvudet.

Example

GET /v1.0/me HTTP/1.1
Host: https://secondwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQ…

Beviljandeflöde för klientautentiseringsuppgifter

Du kan använda OAuth 2.0-klientautentiseringsuppgifterna som anges i RFC 6749 för att få åtkomst till webbaserade resurser med hjälp av identiteten för ett program. Den här typen av beviljande används ofta för server-till-server-interaktioner som måste köras i bakgrunden, utan omedelbar interaktion med en användare. Dessa typer av program kallas ofta för daemoner eller tjänstkonton.

Med OAuth 2.0-klientens autentiseringsuppgifter kan en webbtjänst (konfidentiell klient) använda sina egna autentiseringsuppgifter, i stället för att personifiera en användare, för att autentisera när en annan webbtjänst anropas. I det här scenariot är klienten vanligtvis en mellannivåwebbtjänst, en daemontjänst eller en webbplats. För en högre säkerhetsnivå tillåter AD FS även att den anropande tjänsten använder ett certifikat (i stället för en delad hemlighet) som autentiseringsuppgifter.

Protokolldiagram

Följande diagram visar flödet för beviljande av klientautentiseringsuppgifter.

Begära en token

Om du vill hämta en token med hjälp av beviljandet av klientautentiseringsuppgifter skickar du en POST begäran till AD FS-slutpunkten /token, enligt följande avsnitt.

Första fallet: Åtkomsttokenbegäran med en delad hemlighet

POST /adfs/oauth2/token HTTP/1.1
// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

Andra fallet: Begäran om åtkomsttoken med ett certifikat

POST /adfs/oauth2/token HTTP/1.1

// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials

Använd en token

Nu när du har skaffat en token använder du token för att göra begäranden till resursen. När token upphör att gälla upprepar du begäran till slutpunkten /token för att hämta en ny åtkomsttoken.

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Resursägarens lösenordsautentiseringsuppgifter beviljar flöde (rekommenderas inte)

Med hjälp av ROPC-beviljande (resource owner password credential) kan en applikation logga in användaren genom att direkt hantera deras lösenord. ROPC-flödet kräver en hög grad av förtroende och användarexponering. Du bör bara använda det här flödet när du inte kan använda andra flöden som är säkrare.

Protokolldiagram

Följande diagram visar ROPC-flödet.

Auktoriseringsbegäran

ROPC-flödet är en enskild begäran – det skickar klientidentifieringen och användarens autentiseringsuppgifter till IDP:n och tar sedan emot token i gengäld. Klienten måste begära användarens e-postadress (UPN) och lösenord innan du gör det. Omedelbart efter en lyckad begäran bör klienten på ett säkert sätt frigöra användarens autentiseringsuppgifter från minnet. Det får aldrig rädda dem.

// Line breaks and spaces are for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope= openid
&username=myusername@contoso.com
&password=SuperS3cret
&grant_type=password

Lyckat autentiseringssvar

I följande exempel visas ett lyckat tokensvar:

{
    "token_type": "Bearer",
    "scope": "openid",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}

Du kan använda uppdateringstoken för att hämta nya åtkomsttoken och uppdateringstoken med hjälp av samma flöde som beskrivs i avsnittet för beviljande av autentiseringskod i den här artikeln.

Enhetskodflöde

Med enhetskodsbeviljande kan användare logga in på indatabegränsade enheter, till exempel en smart-TV, IoT-enhet eller skrivare. För att aktivera det här flödet, instruerar enheten användaren att besöka en webbsida i sin webbläsare på en annan enhet för att logga in. När användaren har loggat in kan enheten hämta åtkomsttoken och uppdateringstoken efter behov.

Protokolldiagram

Hela enhetskodflödet liknar det flöde som visas i nästa diagram. Vart och ett av stegen beskrivs senare i den här artikeln.

Begäran om enhetsauktorisering

Klienten måste först kontrollera med autentiseringsservern om en enhet och användarkod som används för att initiera autentisering. Klienten samlar in den här begäran från slutpunkten /devicecode. I den här begäran ska klienten även ange de behörigheter som krävs för att erhålla från användaren. Från den tidpunkt då den här begäran skickas har användaren bara 15 minuter på sig att logga in (det vanliga värdet för expires_in), så gör bara den här begäran när användaren har angett att de är redo att logga in.

// Line breaks are for legibility only

POST https://adfs.contoso.com/adfs/oauth2/devicecode
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
scope=openid

Enhetsauktoriseringssvar

Ett lyckat svar är ett JSON-objekt som innehåller den information som krävs för att användaren ska kunna logga in.

Autentisera användaren

När klienten har fått user_code och verification_uri visas informationen för användaren och instrueras att logga in med hjälp av deras mobiltelefon eller datorwebbläsare. Dessutom kan klienten använda en QR-kod eller liknande mekanism för att visa verfication_uri_complete, vilket tar steget att ange user_code för användaren. Medan användaren autentiserar sig vid verification_uri bör klienten avsöka /token-slutpunkten för den begärda tokenen med hjälp av device_code.

POST https://adfs.contoso.com /adfs/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type: urn:ietf:params:oauth:grant-type:device_code
client_id: 00001111-aaaa-2222-bbbb-3333cccc4444
device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8

Lyckat autentiseringssvar

Ett lyckat tokensvar kan innehålla följande parametrar:

Relaterat innehåll

I AD FS Development finns en fullständig lista över genomgångsartiklar som innehåller stegvisa instruktioner om hur du använder relaterade flöden.