モバイル・アプリケーションの追加
OAuth 2.0を使用するモバイル・アプリケーションを追加します。これらはクライアント・シークレットの機密性を保持することはできません。
- 「ドメイン」リスト・ページで、変更するドメインを選択します。ドメインのリスト・ページの検索に関するヘルプが必要な場合は、アイデンティティ・ドメインのリストを参照してください。
- 詳細ページで、「統合アプリケーション」を選択します。ドメイン内のアプリケーションのリストが表示されます。
- 「アプリケーションの追加」を選択します。
- 「アプリケーションの追加」ウィンドウで、「モバイル・アプリケーション」を選択します。
- 「ワークフローの起動」を選択します。
-
「アプリケーションの追加」詳細ページで、次の表を使用してアプリケーションの詳細を構成します。
オプション 説明 名前 モバイル・アプリケーションの名前を入力します。最大で125文字を入力できます。
長い名前が付いたアプリケーションの場合、そのアプリケーション名は切り捨てられて「自分のアプリ」ページに表示されます。アプリケーション名は、できるだけ短くすることを検討してください。
説明 モバイル・アプリケーションの説明を入力します。最大で250文字を入力できます。
「アプリケーション」アイコン 「アプリケーション」アイコン・ウィンドウで「閉じる」(X)を選択して、デフォルトのアプリケーション・アイコンを削除してから、アプリケーションに独自のアイコンを追加します。このアイコンは、「自分のアプリケーション」ページおよび「アプリケーション」ページのアプリケーション名の横に表示されます。
カスタム・サインインURL 「カスタム・サインインURL」フィールドに、カスタム・サインインURLを指定します。ただし、IAMによって提供されるデフォルトのログイン・ページを使用する場合は、このフィールドを空白のままにします。
カスタム・サインアウトURL 「カスタム・サインアウトURL」フィールドに、カスタム・サインアウトURLを指定します。ただし、IAMによって提供されるデフォルトのログイン・ページを使用する場合は、このフィールドを空白のままにします。
カスタム・エラーURL これはオプションのフィールドです。失敗した場合にユーザーをリダイレクトする必要があるエラー・ページURLを入力します。指定しない場合は、ドメイン固有のエラー・ページURLが使用されます両方のエラーURLが構成されていない場合、エラーはIAMエラー・ページ(/ui/v1/error)にリダイレクトされます。
ユーザーがソーシャル認証(Google、Facebookなど)を使用してIAMにログインしようとする場合、「カスタム・エラーURL」フィールドにコールバックURLを構成する必要があります。ソーシャル・プロバイダは、IAMをコールしてソーシャル認証後にレスポンスを返送するには、このコールバックURLが必要です。指定されたコールバックURLは、ユーザーが存在するかどうか(これが初回のソーシャル・ログインの場合)を検証するために使用され、ソーシャル認証に失敗した場合はエラーが表示されます。
カスタム・ソーシャル・リンク・コールバックURL これはオプションのフィールドです。ソーシャル・プロバイダとIAM間のユーザーのリンクが完了した後にIAMがリダイレクトできるURLを入力します。
IAMカスタムSDKを使用してカスタム・アプリケーションを作成し、IAMソーシャル・ログインに統合する場合、カスタム・アプリケーションには、ソーシャル・プロバイダおよびIAM間のユーザーの関連付けが完了した後にリダイレクトできる「カスタム・ソーシャル・リンク」コールバックURLが必要です。
「自分のアプリケーション」に表示 モバイル・アプリケーションがユーザーの「自分のアプリケーション」(My Apps)ページにリストされるようにする場合は、チェックボックスを選択します。この場合、アプリケーションをリソース・サーバーとして構成する必要があります。
アプリケーションの「「自分のアプリに表示」チェックボックスを選択すると、そのアプリケーションは「自分のアプリ」ページに表示されますが、このチェックボックスを選択しても、アプリケーションに対するSSOを有効または無効になりません。
SSOを有効化または無効化するフラグは、アプリケーション・テンプレートから取得されます。このフラグを更新には、IAM REST APIを使用します。UIからSSOフラグを設定することはできません。
ユーザーにアクセス権のリクエストを許可 アプリケーションをカタログにリストする場合は、「ユーザーにアクセスメントのリクエストを許可」チェック・ボックスを選択します。このオプションを使用すると、エンド・ユーザーは、「追加」を選択し、「カタログ」からアプリケーションを選択することで、自分の「自分のアプリ」ページからアプリへのアクセス権をリクエストできるようになります。
権限付与を認可として実施 エンド・ユーザーが「アクセス権の追加」を選択して、「自分のアプリケーション」ページからアプリへのアクセスをリクエストできるようにする場合は、このボックスを選択します。セルフサービスが使用可能になっていない場合、ユーザーには「アクセス権限の追加」ボタンが表示されません。
- 「次へ」を選択します。
-
「モバイル・アプリケーションの追加」ページの「認可」セクションで、次の表を使用してアプリケーションの詳細を構成します。
オプション 説明 許可される権限付与タイプ 検証をリクエストするときに、このアプリケーションでの使用を許可する権限付与タイプを選択します。- 「リフレッシュ・トークン」権限付与タイプは、認可サーバーによって提供されるリフレッシュ・トークンを要求し、それを使用して新しいアクセス・トークンを取得する場合に選択します。リフレッシュ・トークンは、現在のアクセス・トークンが無効または期限切れになり、リソース所有者が再認証を必要としない場合に使用されます。
-
認可サーバーをクライアント・アプリケーションとリソース所有者との間の仲介として認可コードを取得する場合、「認可コード」チェック・ボックスを選択します。
認可コードは、リソース所有者が認可サーバーに承諾を与えた後、ブラウザ・リダイレクトを介してクライアントに返されます。その後、クライアントは認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークン)に交換します。リソース所有者の資格証明はクライアントに公開されません。
-
アプリケーションが認可サーバーによる認証で使用するクライアント資格証明の機密を保持できない場合に、「暗黙的」チェック・ボックスを選択します。
アクセス・トークンは、中間認可コードではなく、リソース所有者の認可リクエストに応答してブラウザ・リダイレクトを介してクライアントに返されます。
-
クライアントがOAuth認可サーバーからリクエストを受信できない場合(ゲーム・コンソール、ストリーミング・メディア・プレーヤー、デジタル画像フレームなど、HTTPサーバーとして機能できない場合)は、「デバイス・コード」権限付与タイプを選択します。
このフローで、クライアントは、ユーザー・コード、デバイス・コードおよび検証URLを取得します。次に、ユーザーは、個別のブラウザで検証URLにアクセスしてアクセス・リクエストを承認します。その後にのみ、クライアントはデバイス・コードを使用してアクセス・トークンを取得できます。
HTTPS以外のURLを許可 「リダイレクトURL」、「ログアウトURL」または「ログアウト後のリードURL」フィールドにHTTPのURLを使用する場合は、このチェック・ボックスをオンにします。たとえば、内部的にリクエストを送信している場合、暗号化されない通信が必要な場合に、またはOAuth 1.0との下位互換性が必要な場合は、HTTP URLを使用できます。
また、アプリケーションを開発またはテスト中でもSSLを構成していない場合にも、このボックスを選択します。このオプションは利便性のために用意されたもので、本番デプロイメントではお薦めしません。
リダイレクトURL 認証後にユーザーがリダイレクトされるアプリケーションURLを入力します。必要に応じて、別のリダイレクトURLを追加します。
ログアウト後のリダイレクトURL アプリケーションからのログアウト後にユーザーをリダイレクトするURLを入力します。必要に応じて、別のログアウト後のリダイレクトURLを追加します。
ログアウトURL アプリケーションからのログアウト後にユーザーがリダイレクトされるURLを入力します。
許可された操作 「代理」チェック・ボックスを選択します。これにより、クライアント・アプリケーションは、そのクライアント・アプリケーション自体が通常はアクセスできない場合でも、ユーザーがアクセスできるエンドポイントにアクセスできるように、ユーザーの権限のみからアクセス権限を生成できるようにする場合に選択します。
同意のバイパス 有効にすると、この属性によって、アプリケーションに対して構成されているすべてのスコープに対して「同意が必要」属性が上書きされ、スコープが不要になります。
クライアントIPアドレス - 任意の場所: トークン・リクエストはどこからでも許可されます。境界がありません。
- ネットワーク・ペリメータによる制限: ネットワーク・ペリメータを選択して、そこからトークン・リクエストのみが許可されるようにします。
リソースの追加 自分のアプリケーションが他のアプリケーションのAPIにアクセスする場合は、「トークン発行ポリシー」セクションで「スコープの追加」を選択してください。次に、「スコープの追加」ウィンドウで、自分のアプリケーションが参照するアプリケーションを選択します。
アプリケーション・ロールの追加 「追加」を選択して、モバイル・アプリケーションがIAM APIにアクセスできるようにします。
アプリケーション・ロールの追加ウィンドウで、このアプリケーションに割り当てるアプリケーション・ロールを選択しますこれにより、アプリケーションは、割り当てられた各アプリケーション・ロールでアクセス可能なREST APIにアクセスできるようになります。
たとえば、リストから「Identity Domain Administrator」を選択します。アプリケーションでは、アイデンティティ・ドメイン管理者が使用可能なすべてのREST APIタスクにアクセスできるようになります。
必要なアプリケーション・ロールの行の「x」アイコンを選択すると、アプリケーション・ロールを削除できます。
ノート:保護されたアプリケーション・ロールは削除できません。
- 「終了」を選択します。メッセージによって、アプリケーションが非アクティブ状態で追加されたことを確認します。アプリケーションをアクティブ化するには、アプリケーションのアクティブ化を参照してください。
- アプリケーションの「一般情報」セクションにクライアントIDが表示されることに注意してください。アプリケーションと統合するには、このIDを接続設定の一部として使用します。モバイル・アプリケーションはモバイル・デバイスで実行されるため、このタイプのアプリケーションにはクライアント・シークレットが生成されません。