AD FS OpenID Connect/OAuth 流程和應用程式案例

適用於 Active Directory 同盟服務 （AD FS） 2019 和更新版本

隱含授與流程

針對單頁應用程式 （AngularJS、Ember.js、React.js等），AD FS 支援 OAuth 2.0 隱含授與流程。 隱含流程在 OAuth 2.0 規格中說明。 其主要優點是可讓應用程式從 AD FS 取得權杖，而不需要執行後端伺服器認證交換。 此流程可讓應用程式在用戶端 JavaScript 程式碼中登入使用者、維持工作階段，並獲得其他 Web API 的權杖。 使用隱含流程時，需要考慮幾項重要的安全性問題，尤其是針對客戶端。

如果您想要使用隱含流程和 AD FS 將驗證新增至 JavaScript 應用程式，請遵循下列區段中的一般步驟。

通訊協議圖表

下圖顯示整個隱含登入流程的外觀。 下列各節會更詳細地說明每個步驟。

要求 ID 令牌和存取令牌

若要一開始將使用者登入您的應用程式，您可以傳送 OpenID Connect 驗證要求，並從 AD FS 端點取得id_token和存取權杖。

// 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

此時，系統會要求使用者輸入其認證並完成驗證。 使用者驗證之後，AD FS 授權端點會使用 response_mode 參數中指定的方法，將回應傳送至指定的 redirect_uri 給應用程式。

成功回應

當使用 response_mode=fragment and response_type=id_token+token 時，成功的回應如下所示：

// 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

重新整理令牌

隱式授權不提供重新整理令牌。 id_tokens和access_tokens都會在短時間內過期，因此您的應用程式必須準備好定期刷新這些代幣。 若要刷新任一型別的權杖，您可以執行與上一節相同的隱藏iframe請求，使用 prompt=none 引數來控制身分平台的行為。 如果您想收到新的 id_token，請務必使用 response_type=id_token。

授權碼授與流程

您可以在 Web 應用程式中使用 OAuth 2.0 授權碼授與，以取得受保護資源 （例如 Web API） 的存取權。 如需 OAuthh 2.0 授權碼流程的說明，請參閱 OAuth 2.0 規格的第 4.1 節。 其用來在大部分的應用程式類型 (包括 Web 應用程式和原生安裝的應用程式) 中執行驗證和授權。 此流程可讓應用程式安全地取得 access_tokens，以用來存取信任 AD FS 的資源。

通訊協議圖表

概略地說，原生應用程式的驗證流程看起來像這樣：

要求授權碼

授權碼流程的開頭是用戶端將使用者導向至 /authorize 端點。 在此要求中，用戶端會指出其需要向使用者取得的權限：

// 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

此時，系統會要求使用者輸入其認證並完成驗證。 使用者驗證之後，AD FS 會使用參數中redirect_uri指定的方法，在指定的 response_mode處傳回應用程式的回應。

成功回應

使用 response_mode=query 時，成功的回應如下所示：

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

要求存取權杖

現在您已取得 authorization_code，並已獲得使用者權限，您可以將 access_token 的程式碼兌換為所需資源。 將 POST 要求傳送至 /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)

成功回應

成功的令牌回應如下所示：

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

使用存取令牌

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

重新整理權杖授與流程

Access_tokens 的存留期較短，您必須在過期後重新整理，才能繼續存取資源。 若要這麼做，您可以向 /token 端點提交另一個 POST 要求，但這次提供 refresh_token，而不是程式碼。 刷新權杖適用於客戶端已獲取存取權杖的所有許可權。

刷新權杖沒有確定的存留時間。 一般而言，刷新權杖的存留期相對較長。 不過，在某些情況下，刷新權杖可能會過期、被撤銷，或者沒有執行所需動作的足夠的權限。 您的應用程式必須預期並正確處理權杖發行端點所傳回的錯誤。

雖然刷新權杖在用來獲取新的存取權杖時不會被撤銷，但您仍應丟棄舊的刷新權杖。 OAuth 2.0 規範說：“授權服務器可以發出新的刷新令牌，在這種情況下，客戶端必須丟棄舊的刷新令牌並將其替換為新的刷新令牌。 授權伺服器在向用戶端發出新的重新整理權杖之後，可以撤銷舊的重新整理權杖。」當新的重新整理權杖存留期長於先前的重新整理權杖存留期時，AD FS 會發出重新整理權杖。 若要檢視 AD FS 重新整理權杖存留期的其他資訊，請參閱 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)

成功回應

成功的令牌回應如下所示：

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

OAuth 的 PKCE（授權碼交換驗證金鑰）支援

使用授權碼授與的 OAuth 公用用戶端容易受到授權碼攔截攻擊，如 RFC 7636 中所述。 為了減輕這些攻擊，從 Windows Server 2019 開始，AD FS 支援 OAuth 授權碼授與流程的程式代碼交換證明金鑰 （PKCE）。

PKCE 支援規格會將更多參數新增至 OAuth 2.0 授權和存取權杖要求。 下圖顯示用戶端在 Windows Server 2019 中連絡 AD FS 時的 PKCE 程式大綱。

在標示為 A 的區段中，用戶端會建立並記錄名為 code_verifier 的秘密，並衍生名為 t(code_verifier)的已轉換密碼版本，也稱為 code_challenge。 然後，用戶端會在 OAuth 2.0 授權要求中傳送密碼以及 t_m 轉換方法。

在標示為 B 的區段中，授權端點會如往常回應，但會記錄 t(code_verifier) 秘密和轉換方法。

在標示為 C 的區段中，用戶端會像往常一樣傳送存取權杖要求中的授權碼，但包含 code_verifier 區段 A 中產生的密碼。

在標示為 D 的區段中，AD FS 會 code_verifier轉換秘密，並將它與區段 B 中的秘密進行 t(code_verifier) 比較。如果其值不相等，AD FS 會拒絕存取。

如何在 Windows Server 2019 中為相同的規則原則選擇多個驗證提供者

AD FS 已經支援根據宣告規則原則 （RP） 觸發額外的驗證。 您可以為特定 RP 或全域層級設定這些原則。 您可以以系統管理員身分開啟 PowerShell，並執行 Set-AdfsRelyingPartyTrust Cmdlet，傳遞 AdditionalAuthenticationRules 或 AdditionalAuthenticationRulesFile 參數，以設定特定 RP 的額外驗證原則。 若要全域設定，系統管理員可以使用 Set-AdfsAdditionalAuthenticationRule Cmdlet。 設定額外的原則可讓您針對相同的應用程式使用多個驗證提供者。

聲明規則提供選項來選擇驗證提供者以進行額外的驗證，這在客戶在提供者之間切換或針對特定應用程式需要不同的提供者時，非常有用。 從 Windows Server 2019 開始，您可以使用宣告規則來決定要叫用哪些其他驗證提供者來進行額外的驗證。 此功能在兩種情況下很有用：

• 使用者正在從一個身份驗證提供者轉換到另一個身份驗證提供者。 當您將用戶上線至較新的驗證提供者時，他們可以使用群組來控制服務所使用的額外驗證提供者。

• 使用者需要特定應用程式的特定額外驗證提供者，但也需要使用其他應用程式的不同方法。

您可以從其他驗證原則執行下列命令來設定這些設定：

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" );' 

若要設定此規則，您必須從其他驗證原則發出宣告 http://schemas.microsoft.com/claims/authnmethodsproviders 。 此宣告的值應該是 驗證提供者的 Name 變數。

您也可以修改此規則組態，協助使用者從一個驗證提供者轉換到另一個驗證提供者。 例如，假設您想要修改您管理的一個群組，以使用 Microsoft Entra 多重要素驗證 （MFA），以及一個群組以使用憑證作為額外的驗證提供者。

如果您想要追蹤有多少人註冊 MFA 和憑證驗證，您可以執行如下命令，並將值取代為與您的組織相關的值：

'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");’ 

接下來，您可以執行下列命令，將第一個應用程式 （稱為 AppA） 設定為使用 MFA 作為額外的驗證提供者：

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");' 

最後，您可以執行下列命令，將第二個應用程式 （稱為 AppB） 設定為使用憑證作為額外的驗證提供者：

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");' 

系統管理員也可以制定規則，以允許多個額外的驗證提供者。 在此情況下，AD FS 會顯示已發出的驗證方法提供者，而且使用者可以選擇其中任何一個。 若要允許多個額外的驗證提供者，他們應該使用 值 http://schemas.microsoft.com/claims/authnmethodsproviders發出多個宣告。

如果宣告評估未傳回任何驗證提供者，AD FS 會恢復之前狀態並顯示一份清單，列出系統管理員在AD FS 上設定的所有額外驗證提供者。 然後，使用者必須手動選取適當的驗證提供者。

如果您慣用的驗證提供者不在清單中，您可以執行下列 Cmdlet 來檢視所有支援的提供者：

(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

您用於宣告的 http://schemas.microsoft.com/claims/authnmethodsproviders 值應該是 AD FS 所提供的提供者清單中的其中一個提供者名稱。

AD FS 不支援在 AD FS Windows Server 2016 中的存取控制原則時啟用特定的額外驗證提供者。 當您將應用程式移出存取控制原則時，AD FS 會將對應的原則從存取控制原則複製到 AdditionalAuthenticationRules 和 IssuanceAuthorizationRules。 如果系統管理員想要使用特定的驗證提供者，他們應該停止使用存取控制原則，改為修改 AdditionalAuthenticationRules。

代理者流程

OAuth 2.0 代替流程 (OBO) 用於處理應用程式叫用一個服務/Web API，而該 API 接著需要再呼叫另一個服務/Web API 的使用案例。 其概念是透過要求鏈傳播委派的使用者身分識別和權限。 若要讓中階層服務向下游服務提出已驗證的請求，它必須代表使用者從 AD FS 取得存取權杖。

通訊協議圖表

假設使用者使用上一節所述的 OAuth 2.0 授權碼授與流程在應用程式上進行驗證。 此時，應用程式持有一個 API A 的存取權杖 (權杖 A)，其中包含使用者的宣告，並同意存取中層 Web API (API A)。 請確定用戶端要求存取權杖中的「user_impersonation」範圍。 現在，API A 必須向下游 Web API (API B) 提出已驗證的要求。

接下來的步驟會構成 OBO 流程，我們會透過下圖的協助加以說明。

1. 用戶端應用程式會使用權杖 A 向 API A 提出要求。（當您在 AD FS 中設定 OBO 流程時，請確定已選取範圍 user_impersonation ，且用戶端在要求中要求 user_impersonation 範圍。
2. API A 會向 AD FS 權杖發行端點進行驗證，並要求權杖以存取 API B。（當您在 AD FS 中設定此流程時，請確定 API A 也已註冊為伺服器應用程式，其用戶端識別碼與 API A 中的資源識別碼具有相同的值。
3. AD FS 權杖發行端點會使用權杖 A 來驗證 API A 的認證，並發出 API B 的存取權杖 (權杖 B)。
4. 令牌 B 設定在 API B 的請求授權標頭中。
5. API B 會傳回來自受保護資源的資料。

服務間存取權杖請求

若要要求存取權杖，請使用下列各節所述的參數，對 AD FS 權杖端點進行 HTTP POST。

第一個案例：請求存取權杖並使用共享密鑰

對於共用祕密，服務對服務存取權杖要求會包含下列參數：

Example

下列 HTTP POST 請求存取權杖和更新權杖。

// 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

第二個案例：含有憑證的存取權杖要求

含有憑證的服務對服務存取權杖要求會包含下列參數：

請注意，參數幾乎相同。 此範例與使用共享祕密的請求類似，不同之處在於 client_secret 參數被以下兩個參數取代：client_assertion_type 和 client_assertion。

Example

下列 HTTP POST 要求以憑證獲取 Web API 的存取權杖。

// 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

服務對服務存取令牌回應

成功回應是具有下列參數的 JSON OAuth 2.0 回應。

成功的回應範例

下列範例顯示在請求網路 API 存取權杖時的成功回應。

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

使用存取令牌來存取受保護的資源

現在，中介層服務可以使用在上一個回應範例中取得的權杖，向下游 Web API 提出經過驗證的要求。 在 Authorization 標頭中設定權杖。

Example

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

用戶端認證授與流程

您可以使用 RFC 6749 中指定的 OAuth 2.0 用戶端認證授與，使用應用程式的身分識別來存取 Web 託管資源。 這類型的授權常用於必須在背景中運行的伺服器對伺服器互動，無需與使用者直接互動。 這些類型的應用程式通常稱為精靈或服務帳戶。

OAuth 2.0 用戶端認證授與流程可允許 Web 服務 (機密用戶端) 在呼叫其他 Web 服務時，使用自己的認證來驗證，而不是藉由模擬使用者。 在此案例中，用戶端通常是中介層 Web 服務、精靈服務或網站。 為了獲得更高層級的保證，AD FS 也允許呼叫服務使用憑證 （而不是共用密碼） 作為認證。

通訊協議圖表

下圖顯示用戶端認證授與流程。

請求令牌

若要使用用戶端認證授與來取得權杖，請將要求傳送 POST 至 /token AD FS 端點，如下列各節所示。

第一個案例：請求存取權杖並使用共享密鑰

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

第二個案例：含有憑證的存取權杖要求

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

使用代幣

現在您已取得權杖，可使用權杖對資源提出要求。 當權杖過期時，請對 /token 端點重複提出要求，以取得全新的存取權杖。

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

資源擁有者密碼認證授與流程 （不建議）

資源擁有者密碼認證 (ROPC) 授與可讓應用程式直接處理其密碼來登入使用者。 ROPC 流程需要高度的信任和使用者參與。 只有在您無法使用其他更安全的流程時，才應使用此流程。

通訊協議圖表

下圖顯示 ROPC 流程。

授權要求

ROPC 流程是一個單一請求，它會將用戶端識別和使用者的憑證傳送至 IDP，然後接收傳回的令牌。 在這麼做之前，用戶端必須要求使用者的電子郵件地址 (UPN) 和密碼。 要求成功之後，用戶端應會立即從記憶體中安全地釋出使用者認證。 絕對不能儲存它們。

// 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

成功的驗證回應

下列範例會顯示成功的令牌回應：

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

您可以使用刷新權杖來取得新的存取權杖和刷新權杖，使用本文中授權碼授與流程一節所述的相同流程。

裝置代碼流程

裝置代碼授與可讓使用者登入輸入受限的裝置，例如智慧型電視、IoT 裝置或印表機。 若要啟用此流程，裝置會讓使用者在其他裝置的瀏覽器中造訪網頁以進行登入。 使用者登入後，裝置就能視需要取得訪問令牌和重新整理令牌。

通訊協議圖表

整個裝置程式碼流程與下圖所示的流程類似。 本文稍後會說明每個步驟。

裝置授權要求

用戶端必須先向驗證伺服器確認用來起始驗證的裝置和使用者代碼。 用戶端從 /devicecode 端點收集此要求。 在此要求中，用戶端也應包含需要向使用者取得的權限。 從傳送此要求開始，使用者只有 15 分鐘的時間登入 （expires_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

裝置授權回應

成功的回應是 JSON 物件，其中包含允許使用者登入的必要資訊。

驗證使用者

用戶端收到user_code和verification_uri之後，會向使用者顯示這些詳細數據，指示他們使用行動電話或電腦瀏覽器登入。 此外，客戶端可以使用 QR 代碼或類似的機制來顯示 verification_uri_complete，這樣就可以自動代替使用者輸入 user_code。 當使用者在 verification_uri 進行驗證時，客戶端應該使用 device_code 輪詢要求的 /token 端點以獲取 token。

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

成功的驗證回應

成功的權杖回應可以包含下列參數：

相關內容

如需逐步解說文章的完整清單，請參閱 AD FS 開發，其中會提供如何使用相關流程的逐步指示。