エンタープライズサインインの仕組み前提条件ステップ 1: ID プロバイダーに OIDC アプリケーションを作成するステップ 2: IAM アイデンティティセンターで信頼できるトークン発行者を作成するステップ 3: Amazon Quick マネジメントコンソールで拡張機能アクセスを設定するステップ 4: デスクトップアプリケーションをダウンロードして配布するトラブルシューティング

エンタープライズデプロイ用のデスクトップでの Amazon Quick のセットアップ

適用先: Enterprise Edition と Standard Edition

対象者: システム管理者

エンタープライズデプロイでデスクトップ上の Amazon Quick を使用するには、管理者は組織のユーザーが企業の認証情報でサインインできるようにエンタープライズシングルサインオン (SSO) を設定する必要があります。この設定は、組織の OpenID Connect (OIDC) 互換 ID プロバイダー (IdP) を Amazon Quick に接続します。

注記

Free または Plus アカウントを使用している場合、このセクションは適用されません。「はじめに」に進みます。

セットアップには、次の手順が順番に含まれます。

IdP に OIDC アプリケーションを作成します。
IAM アイデンティティセンターに Trusted Token Issuer (TTI) を作成します (認証に IAM アイデンティティセンターを使用するアカウントでのみ必要）。
Amazon Quick マネジメントコンソールで拡張機能アクセスを設定します。
デスクトップアプリケーションをユーザーに配布します。

このガイドでは、Microsoft Entra ID、Okta、および Ping Identity (PingFederate および PingOne) に関する IdP 固有の手順について説明します。以下の特定の ID プロバイダーの手順を参照してください。

エンタープライズサインインの仕組み

Amazon Quick デスクトップアプリケーションは、OIDC プロトコルを使用してユーザーを認証します。ユーザーがエンタープライズログインを選択すると、アプリケーションはブラウザウィンドウを開き、IdP の承認エンドポイントにリダイレクトします。次に、アプリケーションは、コード交換の証明キー (PKCE) を使用して、生成された認可コードをトークンと交換します。

Amazon Quick はトークンを検証し、ユーザーをアカウントの ID にマッピングします。IAM Identity Center を使用するアカウントの場合、TTI は OIDC トークンのemailクレームを ID ストアの emails.value 属性にマッピングします。IAM フェデレーションを使用するアカウントの場合、Amazon Quick はユーザーを E メールで直接マッピングします。いずれの場合も、IdP の E メールアドレスは Amazon Quick のユーザーの E メールアドレスと完全に一致する必要があります。

前提条件

開始する前に、以下があることを確認します。

認証に IAM Identity Center または IAM フェデレーションを使用するアクティブな Amazon Quick サブスクリプションを持つ AWS アカウント。Amazon Quick アカウントのホームリージョン (アイデンティティリージョン) は、米国東部 (バージニア北部) (us-east-1) である必要があります。
Amazon Quick アカウントへの管理者アクセス。
OIDC アプリケーション登録を作成するアクセス許可を持つ IdP へのアクセス。

重要

Amazon Quick アカウントのホームリージョン (アイデンティティリージョン) は、米国東部 (バージニア北部) (us-east-1) である必要があります。デスクトップアプリケーションのすべての推論では、このリージョンも使用されます。ウェブ上の Amazon Quick は他のリージョンで使用できますが、デスクトップアプリケーションは認証と推論の両方のために us-east-1 に接続します。

ステップ 1: ID プロバイダーに OIDC アプリケーションを作成する

IdP にパブリック OIDC クライアントアプリケーションを登録します。Amazon Quick デスクトップアプリケーションは、このクライアントを使用して、PKCE による認可コードフローを通じてユーザーを認証します。クライアントシークレットは必要ありません。

デスクトップアプリケーションでは、存続期間の長いセッションを維持するために更新トークンが必要です。更新トークンの設定方法は、IdP によって異なります。

Microsoft Entra ID – offline_accessスコープを付与する必要があります。これがないと、ユーザーは頻繁に再認証する必要があります。
Okta – 更新トークンの付与タイプはアプリケーションで有効にし、offline_accessスコープを付与する必要があります。
Ping Identity – 更新トークンの付与タイプを有効にし、offline_accessスコープを付与する必要があります。PingFederate の場合、OIDC ポリシーで Return ID Token On Refresh Grant 設定も有効にする必要があります。

ID プロバイダーの手順を選択します。

Microsoft Entra ID

詳細な手順については、Microsoft Entra ドキュメントの「アプリケーションの登録」を参照してください。

Entra ID アプリ登録を作成するには

Azure ポータルで、Microsoft Entra ID → アプリ登録 → 新規登録に移動します。

次の設定を行います。

設定	値
名前	`Amazon Quick Desktop`
サポートされているアカウントタイプ	この組織ディレクトリ内のアカウントのみ (単一テナント)
リダイレクト URI プラットフォーム	パブリッククライアント/ネイティブ (モバイルとデスクトップ)
リダイレクト URI	`http://localhost:18080`

[登録] を選択します。
概要ページで、アプリケーション (クライアント) ID とディレクトリ (テナント) ID を書き留めます。これらの値は、後のステップで必要になります。

これはパブリッククライアント登録です。PKCE は、パブリッククライアントの Entra ID によって自動的に適用されます。

API アクセス許可を設定するには

アプリ登録で、API アクセス許可 → アクセス許可の追加 → Microsoft Graph → 委任アクセス許可に移動します。
次のアクセス許可を追加します: openid、email、profile、offline_access。
[Add permissions (許可の追加)] を選択します。
組織で必要な場合は、[組織] の管理者同意を付与を選択します。

認証設定を構成するには

アプリ登録で、認証に移動します。
詳細設定で、パブリッククライアントフローを許可するを「はい」に設定します。
http://localhost:18080 がモバイルアプリケーションとデスクトップアプリケーションにリストされていることを確認します。
[保存] を選択します。

OIDC エンドポイントは次の形式を使用します。をディレクトリ (テナント) ID <TENANT_ID>に置き換えます。

フィールド	値
発行者 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`

Okta

詳細な手順については、Okta ドキュメントのOpenID Connect アプリ統合の作成」を参照してください。

Okta OIDC ネイティブアプリケーションを作成するには

Okta 管理コンソールで、アプリケーション → アプリケーション → アプリケーション統合の作成に移動します。
サインイン方法として OIDC - OpenID Connect を選択します。
アプリケーションタイプとしてネイティブアプリケーションを選択し、次へを選択します。

次の設定を行います。

設定	値
アプリ統合名	`Amazon Quick Desktop`
グラントタイプ	認可コードと更新トークン
サインインリダイレクト URIs	`http://localhost:18080`
割り当て	適切なユーザーまたはグループにを割り当てる

[保存] を選択します。
全般タブで、クライアント ID を書き留めます。

PKCE (S256) は、ネイティブアプリケーション用に Okta によって自動的に適用されます。

スコープを設定するには

Okta 管理コンソールで、Security → API → Authorization Servers に移動し、認可サーバー (デフォルトなど) を選択します。
スコープタブで、次のスコープが有効になっていることを確認します: openid、email、profile、offline_access。
アクセスポリシータブで、このアプリケーションに割り当てられたポリシーが Authorization Codeおよび Refresh Token 許可タイプを許可していることを確認します。

認証設定を確認するには

アプリ統合で、全般タブに移動します。
全般設定で、アプリケーションタイプがネイティブ、クライアント認証がなし (パブリッククライアント）、PKCE が必要であることを確認します。
LOGIN で、 http://localhost:18080がリダイレクト URI としてリストされていることを確認します。
変更を加えた場合は、保存 を選択します。

OIDC エンドポイントは次の形式を使用します。を Okta ドメイン ( などyour-org.okta.com) <OKTA_DOMAIN>に置き換えます。

フィールド	値
発行者 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 Identity

Ping Identity 製品の手順を選択します。

PingFederate

詳細な手順については、PingFederate での OIDC アプリケーションのセットアップ」を参照してください。

PingFederate OIDC クライアントを作成するには

PingFederate 管理コンソールで、Applications → OAuth → Clients に移動し、Add Client を選択します。
クライアント ID フィールドに、このクライアントの一意の識別子を入力します。
[名前] フィールドに Amazon Quick Desktop を入力してください。
クライアント認証で、なしを選択します。
リダイレクト URI セクションで、「追加」と入力http://localhost:18080し、「追加」を選択します。
許可されたグラントタイプリストで、認可コードと更新トークンを選択します。
コード交換に必要な証明キー (PKCE) チェックボックスをオンにします。
Common Scopes で、、openid、emailprofile、を付与しますoffline_access。
[保存] を選択します。
クライアント ID を書き留めます。この値は、後のステップで必要になります。

OIDC ポリシーを設定するには

PingFederate 管理コンソールで、アプリケーション → OAuth → OpenID Connect ポリシー管理に移動します。
このクライアントに関連付けられた OIDC ポリシーを選択するか、ポリシーの追加を選択して作成します。
更新時の ID トークンの付与を返すチェックボックスをオンにします。これにより、セッションを更新するときに、デスクトップアプリケーションが現在のクレームを含む新しい ID トークンを受信します。
属性契約で、emailクレームが含まれ、認証ソースの対応するユーザー属性にマッピングされていることを確認します。email クレームは、最初の認証と更新トークンの付与の両方で発行されたトークンに存在する必要があります。
[保存] を選択します。

OIDC エンドポイントは次の形式を使用します。を PingFederate サーバーのホスト名<PINGFEDERATE_HOST>に置き換えます。

フィールド	値
発行者 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としてを入力します。
「アプリケーションタイプ」セクションで「ネイティブ」を選択し、「保存」を選択します。

設定タブで、編集を選択し、次の設定を設定します。

設定	値
レスポンスタイプ	コード
グラントタイプ	認可コードと更新トークン
PKCE の適用	S256
リダイレクト URI	`http://localhost:18080`
トークンエンドポイント認証方法	なし

[保存] を選択します。
リソースタブで、、openid、email、 profileのスコープを追加しますoffline_access。
属性マッピングタブで、email属性がユーザーの E メールアドレスにマッピングされていることを確認します。
アプリケーションを Enabled に切り替えます。
設定タブのクライアント ID と環境 ID を書き留めます。

注記

PingOne ドメインはリージョンによって異なります。以下の例では、を使用しています.com。ドメインを環境のドメイン (、、など.eu.asia) .caに置き換えます。

OIDC エンドポイントは次の形式を使用します。を PingOne 環境 ID <ENV_ID>に置き換えます。

フィールド	値
発行者 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: IAM アイデンティティセンターで信頼できるトークン発行者を作成する

注記

このステップは、Amazon Quick アカウントが認証に Identity Center を使用している AWS Identity and Access Management 場合にのみ必要です。アカウントが IAM フェデレーションを使用している場合は、このステップをスキップしてステップ 3 に進みます。

TTI は、IdP からのトークンを信頼し、IAM Identity Center ユーザーにマッピングする方法を IAM Identity Center に指示します。TTI AWS Identity and Access Management は、 Identity Center コンソールまたは CLI AWS で作成できます。

詳細については、AWS Identity and Access Management 「 Identity Center ユーザーガイド」の「信頼できるトークン発行者のセットアップ」を参照してください。

IAM Identity Center コンソールで TTI を作成するには

AWS Identity and Access Management Identity Center コンソールを開きます。
[設定] を選択します。
[設定] ページで、[認証] タブを選択します。
[信頼できるトークン発行者] で [信頼できるトークン発行者を作成] を選択します。

外部 IdP を設定して信頼されたトークンを発行するページの信頼されたトークン発行者の詳細で、以下を設定します。

フィールド	値
発行者 URL	ステップ 1 の OIDC 発行者 URL (以下の表を参照)
信頼できるトークン発行者名	`AmazonQuickDesktop`

マップ属性で、IAM Identity Center がユーザーを検索するために使用する属性マッピングを設定します。

フィールド	値
ID プロバイダー属性	ユーザーを識別する IdP トークンのクレーム (例: `email`)
IAM Identity Center 属性	IAM Identity Center ID ストアの対応する属性 (例: `emails.value`)

重要

ID プロバイダー属性は、IdP がトークンに含めるクレームと一致する必要があり、IAM Identity Center 属性は ID ストア内のユーザーを一意に識別する必要があります。最も一般的なマッピングは email → ですがemails.value、組織は subやカスタムクレームなどの別の属性を使用する場合があります。トークンクレームの値は、IAM Identity Center の対応する属性の値と完全に一致する必要があります。

[信頼できるトークン発行者を作成] を選択します。
信頼できるトークン発行者の ARN を書き留めます。それは次の手順で必要となります。

または、CLI で TTI AWS を作成するには、次のコマンドを実行します。<IDC_INSTANCE_ARN> を IAM Identity Center インスタンスの Amazon リソースネーム (ARN) に置き換え、をステップ 1 の発行者 URL <ISSUER_URL>に置き換えます。


aws sso-admin create-trusted-token-issuer \
  --instance-arn <IDC_INSTANCE_ARN> \
  --name "AmazonQuickDesktop" \
  --trusted-token-issuer-type OIDC_JWT \
  --trusted-token-issuer-configuration '{
    "OidcJwtConfiguration": {
      "IssuerUrl": "<ISSUER_URL>",
      "ClaimAttributePath": "email",
      "IdentityStoreAttributePath": "emails.value",
      "JwksRetrievalOption": "OPEN_ID_DISCOVERY"
    }
  }'

出力TrustedTokenIssuerArnのを書き留めます。それは次の手順で必要となります。

次の表に、各 ID プロバイダーの発行者 URL を示します。

ID プロバイダー	発行者 URL
Microsoft Entra ID	`https://login.microsoftonline.com/<TENANT_ID>/v2.0`
Okta	`https://<OKTA_DOMAIN>/oauth2/default`
PingFederate	`https://<PINGFEDERATE_HOST>`
PingOne	`https://auth.pingone.com/<ENV_ID>/as`

ステップ 3: Amazon Quick マネジメントコンソールで拡張機能アクセスを設定する

拡張機能アクセスを追加するには

Amazon Quick マネジメントコンソールにサインインします。
アクセス許可で、拡張機能アクセスを選択します。
拡張機能アクセスの追加 を選択します。

(オプション) アカウントが IAM Identity Center を使用している場合は、Trusted Token Issuer Setup ステップが表示されます。次のように入力します。

フィールド	値
信頼できるトークン発行者 ARN	ステップ 2 `TrustedTokenIssuerArn`の
Aud クレーム	ステップ 1 のクライアント ID

このステップは、IAM フェデレーションを使用するアカウントには表示されません。

クイック拡張用のデスクトップアプリケーションを選択し、次へを選択します。

Amazon Quick 拡張機能の詳細を入力します。

フィールド	値
名前	この拡張機能アクセスの名前
説明	(オプション) 説明
発行者 URL	ステップ 1 の OIDC 発行者 URL
認可エンドポイント	ステップ 1 の OIDC 認可エンドポイント URL
トークンエンドポイント	ステップ 1 の OIDC トークンエンドポイント URL
JWKS URI	ステップ 1 の JSON ウェブキーセット URI
クライアント ID	ステップ 1 の OIDC クライアント識別子

[Add] (追加) を選択します。

重要
追加を選択する前に、すべての値が正しいことを確認します。拡張機能アクセス設定は、作成後に編集することはできません。値が正しくない場合は、拡張機能アクセスを削除して新しい値を作成する必要があります。

拡張機能を作成するには

Amazon Quick コンソールの「アプリケーションとデータを接続する」の左側のナビゲーションで、「拡張機能」を選択します。
拡張機能の追加 を選択します。
以前に作成したクイック拡張機能アクセス用のデスクトップアプリケーションを選択します。[次へ] を選択します。
[作成] を選択します。

ステップ 4: デスクトップアプリケーションをダウンロードして配布する

エンタープライズサインインを設定したら、デスクトップアプリケーションを自分でダウンロードしてインストールしてセットアップを確認します。サインイン画面でエンタープライズログインを選択し、企業の認証情報で認証して、設定が機能していることを確認します。ダウンロードとインストールの手順については、「」を参照してくださいはじめに。

サインインに失敗した場合は、ステップ 3 で入力した値をステップ 1 の OIDC エンドポイントと照合します。値が正しくない場合は、アクセス許可 → 拡張機能アクセスで拡張機能アクセスを削除し、正しい値でステップ 3 を繰り返します。

セットアップを確認したら、ダウンロード、インストール、サインインの手順はじめにについてをユーザーに指示します。

トラブルシューティング

redirect_mismatch エラー: IdP のリダイレクト URI が正確にhttp://localhost:18080設定されており、パブリッククライアントまたはネイティブプラットフォームとして設定されていることを確認します。
サインイン後にユーザーが見つかりません: IdP トークンの E メールは、IAM Identity Center のユーザーの E メールと完全に一致する必要があります。ユーザーがプロビジョニングされていること、および E メールアドレスが両方のシステムで同一であることを確認します。
トークン検証の失敗: TTI の発行者 URL が IdP の OIDC 設定の発行者 URL と正確に一致することを確認します。
同意またはアクセス許可エラー (Microsoft Entra ID): Azure ポータルで必要な API アクセス許可に対する管理者の同意を付与します。アプリ登録の API アクセス許可ページに移動し、[組織] の管理者同意を付与を選択します。
セッションは頻繁に期限切れになる: IdP が更新トークンを発行するように設定されていることを確認します。Microsoft Entra ID の場合、offline_accessスコープは必須です。Okta の場合、更新トークン許可タイプを有効にし、offline_accessスコープを付与する必要があります。Ping Identity の場合、更新トークンの付与タイプを有効にし、offline_accessスコープを付与する必要があります。PingFederate の場合、OIDC ポリシーで Return ID Token On Refresh Grant が選択されていることを確認します。
invalid_scope エラー (Okta): 認可サーバーで offline_accessが有効になっていることを確認します。Security → API → Authorization Servers → default → Scopes に移動し、スコープが存在することを確認します。また、アプリケーションのアクセスポリシーで、Refresh Token 許可タイプが許可されていることを確認します。
アプリケーションが有効になっていない (PingOne): PingOne ログインページに到達せずに認証がすぐに失敗する場合は、PingOne 管理者コンソールでアプリケーションの切り替えが有効に設定されていることを確認します。
更新後の E メールクレームの欠落 (PingFederate): email クレームが OIDC ポリシー属性契約に含まれ、正しいユーザー属性にマッピングされていることを確認します。マッピングでは、初期認証と更新トークンの付与の両方に対して emailクレームを生成する必要があります。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

デスクトップでの Amazon Quick とは

はじめに