View a markdown version of this page

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

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

 適用先: Enterprise Edition 
   対象者: システム管理者 

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

注記

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

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

  1. IdP に OIDC アプリケーションを作成します。

  2. Amazon Quick マネジメントコンソールで拡張機能アクセスを設定します。

  3. デスクトップアプリケーションをユーザーに配布します。

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

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

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

Amazon Quick はトークンを検証し、ユーザーをアカウントの ID にマッピングします。IdP の E メールアドレスは、Amazon Quick のユーザーの E メールアドレスと完全に一致する必要があります。

前提条件

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

  • アクティブな Amazon Quick サブスクリプションを持つAWSアカウント。Amazon Quick アカウントのホームリージョン (アイデンティティリージョン) は、サポートされている にある必要がありますAWS リージョン。サポートされているリージョンのリストについては「Amazon Quick AWS リージョン でサポート」を参照してください。IAM Identity Center、IAM フェデレーション、ネイティブ Amazon Quick (ユーザー名/パスワード) ユーザーなど、すべての ID タイプがサポートされています。

  • Amazon Quick アカウントへの管理者アクセス。

  • OIDC アプリケーション登録を作成するアクセス許可を持つ IdP へのアクセス。

重要

Amazon Quick on Desktop は、Amazon Quick 機能セット全体AWS リージョンをサポートする のエンタープライズアカウントで使用できます。Amazon Quick 機能のみをサポートするリージョンには、デスクトップは含まれません。利用できるタイムゾーンの一覧については、「Amazon Quick AWS リージョン でサポート」を参照してください。

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

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

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

  • Microsoft Entra ID – offline_accessスコープを付与する必要があります。これがないと、ユーザーは頻繁に再認証する必要があります。

  • Google Workspace – 認可リクエストに access_type=offlineパラメータを含めます。Google は、最初の認可で更新トークンを発行します。追加のスコープまたはグラントタイプの設定は必要ありません。

  • Okta – 更新トークンの付与タイプはアプリケーションで有効にし、offline_accessスコープを付与する必要があります。

  • Ping Identity – 更新トークンの付与タイプを有効にし、offline_accessスコープを付与する必要があります。PingFederate の場合、OIDC ポリシーで Return ID Token On Refresh Grant 設定も有効にする必要があります。

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

Microsoft Entra ID

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

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

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

  2. 次の設定を行います。

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

  3. [登録] を選択します。

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

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

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

  1. アプリ登録で、API アクセス許可 → アクセス許可の追加 → Microsoft Graph → 委任されたアクセス許可に移動します。

  2. 次のアクセス許可を追加します: openid、email、profile、offline_access。

  3. [Add permissions (許可の追加)] を選択します。

  4. 組織で必要な場合は、[組織] の管理者同意を付与を選択します。

認証設定を構成するには

  1. アプリ登録で、認証に移動します。

  2. 詳細設定で、パブリッククライアントフローを許可する を はい に設定します。

  3. http://localhost:18080 がモバイルアプリケーションとデスクトップアプリケーションにリストされていることを確認します。

  4. [保存] を選択します。

トークンクレームを設定するには

  1. アプリ登録で、トークン設定に移動します。

  2. オプションクレームの追加 を選択します。

  3. トークンタイプ ID を選択します。

  4. email クレームを選択し、追加を選択します。

重要

このステップは必須です。email オプションの クレームがない場合、Microsoft Entra ID はユーザーの E メールアドレスを ID トークンに含めず、Amazon Quick はトークンをユーザーにマッピングできません。さらに、サインインする各ユーザーは、Etra ID プロファイル (連絡先情報の下) に Mail 属性を入力する必要があります。ユーザープリンシパル名 (UPN) だけでは不十分です。Mail 属性には値が含まれている必要があります。

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

重要

発行者 URL には/v2.0パスサフィックスを含める必要があります。Entra ID Endpoints パネルに表示される「Authority URL」を使用しないでください。このサフィックスは省略されます。/v2.0 サフィックスがない場合、トークンの検証はサインイン時に「無効な発行者」エラーで失敗します。

フィールド 値
発行者 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 Endpoints パネルに表示されません。これは、エンドポイントパネルから OpenID Connect メタデータドキュメント URL を開き、JSON レスポンスで jwks_uriフィールドを見つけることで確認できます。または、前の表に示す形式を使用して構築します。

Google Workspace

詳細な手順については、Google for Developers ドキュメントのOAuth 2.0 for Mobile & Desktop Apps」を参照してください。

Google OAuth クライアントを作成するには

  1. Google クラウドコンソールで、APIsとサービス → 認証情報 → 認証情報の作成 → OAuth クライアント ID に移動します。

  2. 次の設定を行います。

    設定 値
    アプリケーションタイプ デスクトップアプリ
    名前 Amazon Quick Desktop

  3. [作成] を選択します。

  4. クライアント ID とクライアントシークレットを書き留めます。これらの値は、後のステップで必要になります。

OAuth 同意画面を設定するには

  1. Google クラウドコンソールで、Google 認証プラットフォーム → ブランディングに移動します。

  2. ユーザータイプを内部に設定します。これにより、Google Workspace 組織のユーザーへのサインインが制限されます。

  3. 必要なアプリ情報を入力し、保存を選択します。

スコープを設定するには

  1. Google クラウドコンソールで、Google 認証プラットフォーム → データアクセスに移動します。

  2. 次のスコープを追加します: openid、email、profile。

  3. [保存] を選択します。

Google はデスクトップアプリケーションの PKCE をサポートしています。更新トークンは、 access_type=offlineパラメータが認可リクエストに含まれると自動的に発行されます。追加の設定は必要ありません。

OIDC エンドポイントは次のとおりです。

フィールド 値
発行者 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>。たとえば、。を OAuth クライアント用に生成されたクライアントシークレット<CLIENT_SECRET>に置き換えます。

Okta

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

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

  1. Okta 管理コンソールで、アプリケーション → アプリケーション → アプリケーション統合の作成に移動します。

  2. サインイン方法として OIDC - OpenID Connect を選択します。

  3. アプリケーションタイプとしてネイティブアプリケーションを選択し、次へを選択します。

  4. 次の設定を行います。

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

  5. [保存] を選択します。

  6. 全般タブで、クライアント ID を書き留めます。

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

スコープを設定するには

  1. Okta 管理コンソールで、Security → API → Authorization Servers に移動し、認可サーバー (デフォルトなど) を選択します。

  2. スコープタブで、次のスコープが有効になっていることを確認します: openid、email、profile、offline_access。

  3. アクセスポリシータブで、このアプリケーションに割り当てられたポリシーが Authorization Codeおよび Refresh Token 許可タイプを許可していることを確認します。

認証設定を確認するには

  1. アプリ統合で、全般タブに移動します。

  2. 全般設定で、アプリケーションタイプがネイティブ、クライアント認証がなし (パブリッククライアント）、PKCE が必要であることを確認します。

  3. LOGIN で、 http://localhost:18080がリダイレクト URI としてリストされていることを確認します。

  4. 変更を加えた場合は、保存 を選択します。

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 クライアントを作成するには

  1. PingFederate 管理コンソールで、Applications → OAuth → Clients に移動し、Add Client を選択します。

  2. クライアント ID フィールドに、このクライアントの一意の識別子を入力します。

  3. [名前] フィールドに Amazon Quick Desktop を入力してください。

  4. クライアント認証で、なしを選択します。

  5. リダイレクト URI セクションで、「追加」と入力http://localhost:18080し、「追加」を選択します。

  6. 許可されたグラントタイプリストで、認可コードと更新トークンを選択します。

  7. コード交換に必要な証明キー (PKCE) チェックボックスをオンにします。

  8. 共通スコープで、、openid、emailprofile、 を付与しますoffline_access。

  9. [保存] を選択します。

  10. クライアント ID を書き留めます。この値は、後のステップで必要になります。

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

  1. PingFederate 管理コンソールで、アプリケーション → OAuth → OpenID Connect ポリシー管理に移動します。

  2. このクライアントに関連付けられた OIDC ポリシーを選択するか、ポリシーの追加を選択して作成します。

  3. 更新時の ID トークンの付与を返すチェックボックスをオンにします。これにより、セッションを更新するときに、デスクトップアプリケーションが現在のクレームを含む新しい ID トークンを受信します。

  4. 属性契約で、emailクレームが含まれ、認証ソースの対応するユーザー属性にマッピングされていることを確認します。email クレームは、最初の認証と更新トークンの付与の両方で発行されたトークンに存在する必要があります。

  5. [保存] を選択します。

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 ネイティブアプリケーションを作成するには

  1. PingOne 管理者コンソールで、アプリケーション → アプリケーションに移動し、+ アイコンを選択します。

  2. アプリケーション名Amazon Quick Desktopとして を入力します。

  3. アプリケーションタイプセクションで、ネイティブを選択し、保存を選択します。

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

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

  5. [保存] を選択します。

  6. リソースタブで、、openid、email、 profileのスコープを追加しますoffline_access。

  7. 属性マッピングタブで、email属性がユーザーの E メールアドレスにマッピングされていることを確認します。

  8. アプリケーションを Enabled に切り替えます。

  9. 設定タブのクライアント 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: Amazon Quick マネジメントコンソールで拡張機能アクセスを設定する

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

  1. Amazon Quick マネジメントコンソールにサインインし、アカウントの管理を選択します。

  2. 左側のナビゲーションペインのアクセス許可で、拡張機能アクセスを選択します。

  3. 拡張機能アクセスの追加 を選択します。

  4. サービスの選択 で、Amazon Quick (クイックの場合はデスクトップアプリケーション) を選択し、次へ を選択します。

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

    フィールド 値 注意事項
    名前 この拡張機能アクセスの名前 (例: QuickDesktop-access) 内部リファレンスのみ。この名前は IdP では設定されていません。英数字とハイフンのみ、スペースなし。
    説明 (オプション) この拡張機能アクセスの説明 オプション。参考用です。
    発行者 URL ステップ 1 の OIDC 発行者 URL Entra ID /v2.0 のサフィックスを含める必要があります。
    認可エンドポイント ステップ 1 の OIDC 認可エンドポイント URL
    トークンエンドポイント ステップ 1 の OIDC トークンエンドポイント URL
    JWKS URI ステップ 1 の JSON ウェブキーセット URI
    クライアント ID ステップ 1 の OIDC クライアント識別子

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

    重要

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

拡張機能を作成するには

  1. Amazon Quick マネジメントコンソールの左側のナビゲーションペインで、Quick を選択し、Connect apps and data で Extensions を選択します。

  2. 拡張機能の追加 を選択します。

  3. 以前に作成したクイック拡張機能アクセス用のデスクトップアプリケーションを選択します。[次へ] を選択します。

  4. [作成] を選択します。

重要

両方のステップが必要です。拡張機能を作成せずに拡張機能アクセスのみを設定すると、エンタープライズサインインは使用できず、ユーザーには「クイックデスクトップのエンタープライズサインインはこのアカウントに設定されていません」というエラーが表示されます。

注記

拡張機能の作成は、アカウントレベルの 1 回限りのアクションです。管理者が拡張機能を作成すると、アカウント内のすべてのユーザーがエンタープライズサインインを使用できます。個々のユーザーは、拡張機能を自分で有効にする必要はありません。デスクトップアプリケーションをダウンロードしてサインインするだけで済みます。

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

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

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

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

トラブルシューティング

redirect_mismatch エラー

IdP のリダイレクト URI が正確でありhttp://localhost:18080、パブリッククライアントまたはネイティブプラットフォームとして設定されていることを確認します。

サインイン後にユーザーが見つかりません

このエラーには 2 つの一般的な原因があります。

  1. E メールクレームはトークンで返されません。Microsoft Entra ID の場合、トークン設定の ID トークンにemailオプションのクレームを追加する必要があります (ステップ 1 を参照）。さらに、ユーザーの Mail 属性を Entra ID プロファイルに入力する必要があります。ユーザープリンシパル名 (UPN) だけでは不十分です。

  2. Amazon Quick に一致するユーザーは存在しません。トークン内の E メールは、プロビジョニングされたユーザーの E メールと完全に一致する必要があります。IAM Identity Center アカウントの場合、Identity Center のユーザーの E メールが一致していることを確認します。E メールマッチングでは、大文字と小文字が区別されます。

トークン検証の失敗

拡張機能アクセス設定の発行者 URL が IdP の OIDC 設定の発行者 URL と正確に一致することを確認します。

無効な発行者エラー (Microsoft Entra ID)

「無効な発行者: https://login.microsoftonline.com/TENANT_ID/v2.0」でサインインに失敗した場合、拡張アクセス設定の発行者 URL に/v2.0パスサフィックスが含まれていることを確認します。Entra ID v2.0 エンドポイントは、 を含む issクレームでトークンを発行します/v2.0。サフィックスがない場合は、拡張機能アクセスを削除し、正しい発行者 URL で再作成します。

このアカウントにエンタープライズサインインが設定されていません

このエラーは、拡張機能アクセスが作成されたが、拡張機能自体は作成されなかったことを意味します。管理コンソールでアプリケーションとデータの接続 → 拡張機能に移動し、拡張機能を作成し、以前に設定した拡張機能アクセスを選択します。

ユーザー情報リクエストが失敗しました (HTTP 504)

これは一時的なバックエンドタイムアウトです。まずウェブブラウザから 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 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クレームを生成する必要があります。