本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
在桌面上為企業部署設定 Amazon Quick
| 適用對象:企業版 |
| 目標對象:系統管理員 |
若要在桌面上使用 Amazon Quick 進行企業部署,管理員必須設定企業單一登入 (SSO),以便組織中的使用者可以使用其企業憑證登入。此設定會將組織的 OpenID Connect (OIDC) 相容身分提供者 (IdP) 連線至 Amazon Quick。
注意
如果您使用的是 免費或 Plus 帳戶,本節不適用於您。繼續進行開始使用。
設定會依序包含下列步驟:
-
在 IdP 中建立 OIDC 應用程式。
-
在 Amazon Quick 管理主控台中設定擴充功能存取。
-
將桌面應用程式分發給您的使用者。
本指南提供 Microsoft Entra ID、Google Workspace、Okta 和 Ping Identity (PingFederate 和 PingOne) 的 IdP 特定指示。請參閱以下特定身分提供者的說明。
企業登入的運作方式
Amazon Quick 桌面應用程式使用 OIDC 通訊協定來驗證使用者。當使用者選擇繼續 SSO 時,應用程式會開啟瀏覽器視窗,並重新導向至 IdP 的授權端點。然後,應用程式會使用 Code Exchange 的驗證金鑰 (PKCE) 交換產生的權杖授權碼。
Amazon Quick 會驗證權杖,並將使用者映射至您帳戶中的身分。IdP 中的電子郵件地址必須與 Amazon Quick 中使用者的電子郵件地址完全相符。
先決條件
開始之前,請確認您有下列項目:
-
具有作用中 Amazon Quick 訂閱AWS的帳戶。Amazon Quick 帳戶的所在區域 (身分區域) 必須位於支援的 中AWS 區域。如需支援的區域的清單,請參閱 AWS 區域 支援 Amazon Quick。支援所有身分類型,包括 IAM Identity Center、IAM 聯合和原生 Amazon Quick (使用者名稱/密碼) 使用者。
-
管理員存取您的 Amazon Quick 帳戶。
-
具有建立 OIDC 應用程式註冊許可的 IdP 存取權。
重要
支援AWS 區域完整 Amazon Quick 功能集的企業帳戶可使用 Amazon Quick on 桌面。支援 Amazon Quick 功能的區域不包含桌面。如需完整清單,請參閱AWS 區域 支援 Amazon Quick。
步驟 1:在身分提供者中建立 OIDC 應用程式
在 IdP 中註冊公有 OIDC 用戶端應用程式。Amazon Quick 桌面應用程式使用此用戶端透過授權碼流程搭配 PKCE 來驗證使用者。不需要用戶端秘密。
桌面應用程式需要重新整理權杖來維護長期工作階段。重新整理字符的設定方式取決於您的 IdP:
-
Microsoft Entra ID – 必須授予
offline_access範圍。如果沒有,使用者必須經常重新驗證。 -
Google Workspace – 在授權請求中包含
access_type=offline參數。Google 在第一次授權時發出重新整理權杖。不需要額外的範圍或授予類型組態。 -
Okta – 必須在應用程式上啟用重新整理字符授予類型,並且必須授予
offline_access範圍。 -
Ping 身分 – 必須啟用重新整理字符授予類型,且必須授予
offline_access範圍。對於 PingFederate,也必須在 OIDC 政策中啟用 Return ID Token On Refresh Grant 設定。
選擇身分提供者的指示。
Microsoft Entra ID
如需詳細說明,請參閱 Microsoft Entra 文件中的註冊應用程式
建立 Entra ID 應用程式註冊
-
在 Azure 入口網站中,導覽至 Microsoft Entra ID → 應用程式註冊 → 新註冊。
-
進行下列設定:
設定 Value 名稱 Amazon Quick Desktop支援的帳戶類型 僅限此組織目錄中的帳戶 (單一租戶) 重新導向 URI 平台 公有用戶端/原生 (行動和桌面) 重新導向 URI http://localhost:18080 -
選擇註冊。
-
在概觀頁面上,記下應用程式 (用戶端) ID 和目錄 (租戶) ID。在後續步驟中,您需要這些值。
這是公有用戶端註冊。公有用戶端的 Entra ID 會自動強制執行 PKCE。
設定 API 許可
-
在應用程式註冊中,導覽至 API 許可 → 新增許可 → Microsoft 圖形 → 委派許可。
-
新增下列許可:
openid、email、profile、offline_access。 -
選擇新增許可。
-
如果您的組織需要,請選擇授予 【您的組織】 的管理員同意。
設定身分驗證設定
-
在應用程式註冊中,導覽至身分驗證。
-
在進階設定下,將允許公有用戶端流程設定為是。
-
確認
http://localhost:18080列於 Mobile 和桌面應用程式下。 -
選擇儲存。
設定字符宣告
-
在應用程式註冊中,導覽至字符組態。
-
選擇新增選用宣告。
-
選取字符類型:ID。
-
選取
email宣告,然後選擇新增。
重要
此步驟為必要。如果沒有email選用的宣告,Microsoft Entra ID 不會在 ID 字符中包含使用者的電子郵件地址,而且 Amazon Quick 無法將字符映射至使用者。此外,每個登入的使用者都必須在其 Entra ID 設定檔中填入其郵件屬性 (聯絡資訊下方)。使用者主體名稱 (UPN) 本身不夠,郵件屬性必須包含值。
您的 OIDC 端點使用以下格式。<TENANT_ID> 將 取代為您的目錄 (租戶) ID。
重要
發行者 URL 必須包含/v2.0路徑尾碼。請勿使用 Entra ID 端點面板中顯示的「身分 URL」,這會省略此尾碼。如果/v2.0尾碼遺失,字符驗證會在登入時失敗,並顯示「無效發行者」錯誤。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://login.microsoftonline.com/<TENANT_ID>/v2.0 |
| 授權端點 | https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/authorize |
| 權杖端點 | https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token |
| JWKS URI | https://login.microsoftonline.com/<TENANT_ID>/discovery/v2.0/keys |
提示
JWKS URI 不會顯示在 Microsoft Entra ID 端點面板中。您可以從端點面板開啟 OpenID Connect 中繼資料文件 URL,並在 JSON 回應中尋找 jwks_uri 欄位,即可找到它。或者,使用上表中顯示的格式來建構它。
Google Workspace
如需詳細說明,請參閱 Google for Developers 文件中的適用於行動裝置和桌面應用程式的 OAuth 2.0
建立 Google OAuth 用戶端
-
在 Google 雲端主控台中,導覽至 APIs和服務 → 登入資料 → 建立登入資料 → OAuth 用戶端 ID。
-
進行下列設定:
設定 Value 應用程式類型 桌面應用程式 名稱 Amazon Quick Desktop -
選擇建立。
-
請記下用戶端 ID 和用戶端秘密。在後續步驟中,您需要這些值。
設定 OAuth 同意畫面
-
在 Google 雲端主控台中,導覽至 Google 身分驗證平台 → 品牌。
-
將使用者類型設定為內部。這會將登入限制為您 Google Workspace 組織中的使用者。
-
填寫所需的應用程式資訊,然後選擇儲存。
設定範圍
-
在 Google 雲端主控台中,導覽至 Google 身分驗證平台 → 資料存取。
-
新增下列範圍:
openid、email、profile。 -
選擇儲存。
Google 支援桌面應用程式的 PKCE。重新整理字符會在 access_type=offline 參數包含在授權請求中時自動發出。不需任何其他設定。
您的 OIDC 端點如下所示:
| 欄位 | Value |
|---|---|
| 發行者 URL | https://accounts.google.com |
| 授權端點 | https://accounts.google.com/o/oauth2/v2/auth |
| 權杖端點 | https://oauth2.googleapis.com/token?client_secret=<CLIENT_SECRET> |
| JWKS URI | https://www.googleapis.com/oauth2/v3/certs |
注意
將您的用戶端秘密附加至字符端點做為client_secret查詢參數,讓字符交換成功,例如 https://oauth2.googleapis.com/token?client_secret=<CLIENT_SECRET>。<CLIENT_SECRET> 將 取代為您的 OAuth 用戶端產生的用戶端秘密。
Okta
如需詳細說明,請參閱 Okta 文件中的建立 OpenID Connect 應用程式整合
建立 Okta OIDC 原生應用程式
-
在 Okta 管理員主控台中,導覽至應用程式 → 應用程式 → 建立應用程式整合。
-
選取 OIDC - OpenID Connect 作為登入方法。
-
選取原生應用程式做為應用程式類型,然後選擇下一步。
-
進行下列設定:
設定 Value 應用程式整合名稱 Amazon Quick Desktop授予類型 授權碼和重新整理權杖 登入重新導向 URIs http://localhost:18080指派 指派給適當的使用者或群組 -
選擇儲存。
-
在一般索引標籤上,記下用戶端 ID。
Okta 會自動為原生應用程式強制執行 PKCE (S256)。
設定範圍
-
在 Okta 管理員主控台中,導覽至安全性 → API → 授權伺服器,然後選取您的授權伺服器 (例如預設)。
-
在範圍索引標籤上,確認已啟用下列範圍:
openid、email、profile、offline_access。 -
在存取政策索引標籤上,確認指派給此應用程式的政策允許
Authorization Code和Refresh Token授予類型。
驗證身分驗證設定
-
在應用程式整合中,前往一般索引標籤。
-
在一般設定下,確認應用程式類型為原生,用戶端身分驗證為無 (公有用戶端),且 PKCE 為必要。
-
在 LOGIN 下,確認
http://localhost:18080列為重新導向 URI。 -
如果您進行任何變更,請選擇儲存。
您的 OIDC 端點使用以下格式。<OKTA_DOMAIN> 將 取代為您的 Okta 網域 (例如 your-org.okta.com)。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://<OKTA_DOMAIN>/oauth2/default |
| 授權端點 | https://<OKTA_DOMAIN>/oauth2/default/v1/authorize |
| 權杖端點 | https://<OKTA_DOMAIN>/oauth2/default/v1/token |
| JWKS URI | https://<OKTA_DOMAIN>/oauth2/default/v1/keys |
Ping 身分
選擇 Ping Identity 產品的指示。
PingFederate
如需詳細說明,請參閱 Ping Identity 文件中的在 PingFederate 中設定 OIDC 應用程式
建立 PingFederate OIDC 用戶端
-
在 PingFederate 管理主控台中,前往應用程式 → OAuth → 用戶端,然後選擇新增用戶端。
-
在用戶端 ID 欄位中,輸入此用戶端的唯一識別符。
-
在 Name (名稱) 欄位中,輸入
Amazon Quick Desktop。 -
針對用戶端身分驗證,選取無。
-
在重新導向 URI 區段中,輸入
http://localhost:18080並選擇新增。 -
在允許授予類型清單中,選取授權碼並重新整理權杖。
-
選取 Code Exchange (PKCE) 需要證明金鑰核取方塊。
-
在通用範圍下,授予下列項目:
openid、email、profile、offline_access。 -
選擇儲存。
-
請記下用戶端 ID。在後續步驟中,您需要此值。
設定 OIDC 政策
-
在 PingFederate 管理主控台中,前往應用程式 → OAuth → OpenID Connect 政策管理。
-
選取與此用戶端相關聯的 OIDC 政策,或選擇新增政策來建立政策。
-
選取重新整理授予時傳回 ID 權杖核取方塊。這可確保桌面應用程式在重新整理工作階段時收到具有目前宣告的新 ID 字符。
-
在屬性合約下,確認已包含
email宣告,並映射至身分驗證來源中對應的使用者屬性。email宣告必須同時存在於初始身分驗證和重新整理權杖授予期間發出的權杖中。 -
選擇儲存。
您的 OIDC 端點使用以下格式。<PINGFEDERATE_HOST> 將 取代為您的 PingFederate 伺服器主機名稱。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://<PINGFEDERATE_HOST> |
| 授權端點 | https://<PINGFEDERATE_HOST>/as/authorization.oauth2 |
| 權杖端點 | https://<PINGFEDERATE_HOST>/as/token.oauth2 |
| JWKS URI | https://<PINGFEDERATE_HOST>/pf/JWKS |
PingOne
如需詳細說明,請參閱 Ping Identity 文件中的編輯應用程式 – 原生
建立 PingOne OIDC 原生應用程式
-
在 PingOne 管理員主控台中,前往應用程式 → 應用程式,然後選擇 + 圖示。
-
輸入
Amazon Quick Desktop做為應用程式名稱。 -
在應用程式類型區段中,選取原生,然後選擇儲存。
-
在組態索引標籤上,選擇編輯並設定下列設定:
設定 Value 回應類型 Code 授予類型 授權碼和重新整理權杖 PKCE 強制執行 S256 Redirect URIs (重新導向 URI) http://localhost:18080權杖端點身分驗證方法 無 -
選擇儲存。
-
在資源索引標籤上,新增下列範圍:
openid、email、profile、offline_access。 -
在屬性映射索引標籤上,確認
email屬性已映射至使用者的電子郵件地址。 -
將應用程式切換為已啟用。
-
請注意組態索引標籤中的用戶端 ID 和環境 ID。
注意
PingOne 網域因區域而異。以下範例使用 .com。將網域取代為您環境的網域 (例如 .ca、 .eu或 .asia)。
您的 OIDC 端點使用以下格式。將 取代<ENV_ID>為您的 PingOne 環境 ID。
| 欄位 | Value |
|---|---|
| 發行者 URL | https://auth.pingone.com/<ENV_ID>/as |
| 授權端點 | https://auth.pingone.com/<ENV_ID>/as/authorize |
| 權杖端點 | https://auth.pingone.com/<ENV_ID>/as/token |
| JWKS URI | https://auth.pingone.com/<ENV_ID>/as/jwks |
步驟 2:在 Amazon Quick 管理主控台中設定擴充功能存取
新增擴充功能存取
-
登入 Amazon Quick 管理主控台,然後選擇管理帳戶。
-
在左側導覽窗格的許可下,選擇延伸存取。
-
選擇新增延伸項目存取。
-
在選取服務下,選取 Amazon Quick (適用於 Quick 的桌面應用程式),然後選擇下一步。
-
輸入 Amazon Quick 延伸模組詳細資訊:
欄位 Value 備註 名稱 此延伸存取的名稱 (例如 QuickDesktop-access)僅限內部參考。此名稱未在 IdP 中設定。僅限英數字元和連字號,不含空格。 說明 (選用) 此延伸存取的說明 選用。僅供參考。 發行者 URL 步驟 1 中的 OIDC 發行者 URL 必須包含 Entra ID /v2.0的尾碼。授權端點 步驟 1 中的 OIDC 授權端點 URL 權杖端點 步驟 1 中的 OIDC 字符端點 URL JWKS URI 步驟 1 中的 JSON Web 金鑰集 URI 用戶端 ID 步驟 1 中的 OIDC 用戶端識別符 -
選擇新增。
重要
在選擇新增之前,請確認所有值皆正確。延伸存取組態無法在建立後編輯。如果任何值不正確,您必須刪除延伸存取並建立新的延伸存取。
建立擴充功能
-
在 Amazon Quick 管理主控台的左側導覽窗格中,選擇快速,然後在連線應用程式和資料下,選擇延伸。
-
選擇新增延伸模組。
-
選取桌面應用程式,以進行您先前建立的快速延伸存取。選擇下一步。
-
選擇建立。
重要
這兩個步驟都是必要的。如果您只設定擴充功能存取而不建立擴充功能,則企業登入將無法使用,使用者將看到錯誤:「此帳戶尚未設定 Quick Desktop 的企業登入」。
注意
建立擴充功能是一次性的帳戶層級動作。管理員建立擴充功能後,帳戶中的所有使用者都可以使用企業登入。個別使用者不需要自行啟用擴充功能 - 他們只需要下載桌面應用程式並登入。
步驟 3:下載並分發桌面應用程式
設定企業登入後,請自行下載並安裝桌面應用程式來驗證設定。在登入畫面上選擇企業登入,然後使用您的公司登入資料進行驗證,以確認組態是否正常運作。如需下載和安裝步驟,請參閱 開始使用。
如果登入失敗,請針對步驟 1 的 OIDC 端點,驗證您在步驟 2 中輸入的值。如果任何值不正確,請刪除許可 → 延伸存取下的延伸存取,並使用正確的值重複步驟 2。
驗證設定之後,請將您的使用者導向 開始使用,以取得下載、安裝和登入指示。
疑難排解
redirect_mismatch錯誤-
確認 IdP 中的重新導向 URI 完全是
http://localhost:18080並設定為公有用戶端或原生平台。 - 登入後找不到使用者
-
此錯誤有兩個常見原因:
-
不會在字符中傳回電子郵件宣告。對於 Microsoft Entra ID,您必須將
email選用的宣告新增至字符組態下的 ID 字符 (請參閱步驟 1)。此外,使用者的郵件屬性必須填入其 Entra ID 設定檔中。使用者主體名稱 (UPN) 並不足夠。 -
Amazon Quick 中不存在相符的使用者。字符中的電子郵件必須與佈建使用者的電子郵件完全相符。對於 IAM Identity Center 帳戶,請確認 Identity Center 中的使用者電子郵件相符。電子郵件比對區分大小寫。
-
- 字符驗證失敗
-
確認延伸存取組態中的發行者 URL 與您 IdP 的 OIDC 組態中的發行者 URL 完全相符。
- 發行者錯誤無效 (Microsoft Entra ID)
-
如果登入失敗並顯示「無效發行者:https://https://login.microsoftonline.com/TENANT_ID/v2.0」,請確認延伸存取組態中的發行者 URL 包含
/v2.0路徑尾碼。Entra ID v2.0 端點會以包含 的iss宣告發出權杖。/v2.0如果尾碼遺失,請刪除延伸存取,然後使用正確的發行者 URL 重新建立。 - 此帳戶未設定企業登入
-
此錯誤表示已建立擴充功能存取,但擴充功能本身並未建立。在管理主控台中導覽至連線應用程式和資料 → 延伸模組並建立延伸模組,然後選取您先前設定的延伸模組存取。
- 使用者資訊請求失敗 (HTTP 504)
-
這是暫時性後端逾時。請先透過 Web 瀏覽器登入您的 Amazon Quick 帳戶,然後重試桌面登入。如果錯誤仍然存在,請確認與 Amazon Quick 服務端點的網路連線。
- 同意或許可錯誤 (Microsoft Entra ID)
-
在 Azure 入口網站中授予管理員對必要 API 許可的同意。導覽至應用程式註冊的 API 許可頁面,然後選擇授予 【您的組織】 的管理員同意。
- 工作階段頻繁過期
-
確認您的 IdP 已設定為發出重新整理權杖。對於 Microsoft Entra ID,
offline_access範圍是必要的。對於 Google Workspace,請在授權請求access_type=offline中包含 (由 Quick 自動處理)。對於 Okta,必須啟用重新整理字符授予類型,並且必須授予offline_access範圍。對於 Ping 身分,必須啟用重新整理字符授予類型,並且必須授予offline_access範圍。對於 PingFederate,也請確認已在 OIDC 政策中選取 Return ID Token On Refresh Grant。 invalid_scope錯誤 (Okta)-
確認您的授權伺服器上
offline_access已啟用 。導覽至安全性 → API → 授權伺服器 → 預設 → 範圍並確認範圍存在。同時驗證應用程式的存取政策是否允許重新整理權杖授予類型。 - 應用程式未啟用 (PingOne)
-
如果身分驗證立即失敗,但未到達 PingOne 登入頁面,請確認應用程式切換在 PingOne 管理員主控台中設定為已啟用。
- 重新整理後遺失電子郵件宣告 (PingFederate)
-
確認
email宣告已包含在 OIDC 政策屬性合約中,並對應至正確的使用者屬性。映射必須產生初始身分驗證和重新整理權杖授予的email宣告。