View a markdown version of this page

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

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

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

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

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

注記

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

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

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

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

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

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

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

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

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

前提条件

開始する前に、以下があることを確認してください。

  • アクティブな Amazon Quick サブスクリプションを持つ AWS アカウント。Amazon Quick アカウントのホームリージョン (アイデンティティリージョン) は、米国東部 (バージニア北部) (us-east-1) である必要があります。IAM Identity Center、IAM フェデレーション、ネイティブ Amazon Quick (ユーザー名/パスワード) ユーザーなど、すべての ID タイプがサポートされています。

  • 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 アプリ登録を作成するには

  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. [保存] を選択します。

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

  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。ドメインを環境のドメイン (、、 など) .caに置き換えます.eu.asia。

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. クイック拡張用のデスクトップアプリケーションを選択し、次へを選択します。

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

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

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

    重要

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

拡張機能を作成するには

  1. Amazon Quick コンソールの「アプリケーションとデータを接続する」の左側のナビゲーションで、「拡張機能」を選択します。

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

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

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

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

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

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

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

トラブルシューティング

redirect_mismatch エラー

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

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

IdP トークンの E メールは、Amazon Quick のユーザーの E メールと完全に一致する必要があります。ユーザーがプロビジョニングされており、両方のシステムで E メールアドレスが同じであることを確認します。

トークン検証の失敗

拡張機能アクセス設定の発行者 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クレームを生成する必要があります。