モバイル・アプリケーションの追加
OAuth 2.0を使用していて、クライアント・シークレットの機密性を維持できないモバイル・アプリケーションを追加します。
- 「ドメイン」リスト・ページで、変更するドメインを選択します。ドメインのリスト・ページの検索に関するヘルプが必要な場合は、アイデンティティ・ドメインのリストを参照してください。
- 詳細ページで、「統合アプリケーション」を選択します。ドメイン内のアプリケーションのリストが表示されます。
- 「アプリケーションの追加」を選択します。
- 「アプリケーションの追加」ウィンドウで、「モバイル・アプリケーション」を選択します。
- 「ワークフローの起動」を選択します。
-
「アプリケーションの追加」詳細ページで、次の表を使用してアプリケーションの詳細を構成します。
オプション 説明 名前 モバイル・アプリケーションの名前を入力します。最大で125文字を入力できます。
長い名前が付いたアプリケーションの場合、そのアプリケーション名は切り捨てられて「自分のアプリケーション」ページに表示されます。アプリケーション名は、できるかぎり短くすることを検討してください。
Description モバイル・アプリケーションの説明を入力します。最大で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が必要です。
「自分のアプリケーション」に表示 このチェック・ボックスは、モバイル・アプリケーションをユーザーの「自分のアプリケーション」ページにリストする場合に選択します。この場合、アプリケーションをリソース・サーバーとして構成する必要があります。
アプリケーションの「「マイ・アプリケーション」に表示」チェック・ボックスを選択すると、そのアプリケーションは「マイ・アプリケーション」ページに表示されますが、このチェック・ボックスを選択しても、アプリケーションに対するSSOは有効化または無効化されません。
SSOを有効化または無効化するフラグは、アプリケーション・テンプレートから取得されます。このフラグを更新するには、IAM REST APIを使用します。UIからSSOフラグを設定できません。
ユーザーにアクセス権のリクエストを許可 アプリケーションをカタログにリストする場合は、「ユーザーにアクセス権のリクエストを許可」チェック・ボックスを選択します。このオプションを使用すると、エンド・ユーザーは、「追加」を選択し、「カタログ」からアプリケーションを選択することで、「自分のアプリケーション」ページからアプリケーションへのアクセス権をリクエストできます。
権限付与を認可として実施 エンド・ユーザーが「アクセス権の追加」を選択して「自分のアプリケーション」ページからアプリケーションへのアクセスをリクエストできるようにする場合は、このチェック・ボックスを選択します。セルフサービスが有効でない場合、ユーザーには「アクセス権の追加」ボタンは表示されません。
- 「次」を選択します。
-
「モバイル・アプリケーションの追加」ページの「認可」セクションで、次の表を使用してアプリケーションの詳細を構成します。
オプション 説明 許可される付与タイプ 検証をリクエストするときに、このアプリケーションでの使用を許可する権限付与タイプのチェック・ボックスを選択します。- 「リフレッシュ・トークン」権限付与タイプは、認可サーバーによって提供されるリフレッシュ・トークンを必要とし、それを使用して新しいアクセス・トークンを取得する場合に選択します。リフレッシュ・トークンは、現在のアクセス・トークンが無効または期限切れになり、リソース所有者が再認証を必要としない場合に使用されます。
-
「認可コード」チェック・ボックスは、クライアント・アプリケーションとリソース所有者間の仲介として認可サーバーを使用して、認可コードを取得する場合に選択します。
認可コードは、リソース所有者が認可サーバーに承諾を与えた後、ブラウザのリダイレクトを介してクライアントに返されます。その後、クライアントは認可コードをアクセス・トークン(多くの場合、リフレッシュ・トークン)に交換します。リソース所有者の資格証明はクライアントに公開されません。
-
「Implicit」チェック・ボックスは、アプリケーションが認可サーバーによる認証に使用するクライアント資格証明の機密を保持できない場合に選択します。
アクセス・トークンは、中間認可コードではなく、リソース所有者の認可リクエストに応答してブラウザ・リダイレクトを介してクライアントに返されます。
-
「デバイス・コード」権限付与タイプは、クライアントが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にアクセスできるようになります。
たとえば、リストから「アイデンティティ・ドメイン管理者」を選択します。アプリケーションでは、アイデンティティ・ドメイン管理者が使用可能なすべてのREST APIタスクにアクセスできるようになります。
アプリケーション・ロールを削除するには、必要なアプリケーション・ロールの行にある「x」アイコンを選択します。
ノート: 保護されたアプリケーション・ロールは削除できません。
- 「終了」を選択します。メッセージによって、アプリケーションが非アクティブ状態で追加されたことを確認します。アプリケーションをアクティブ化するには、アプリケーションのアクティブ化を参照してください。
- アプリケーションの「一般情報」セクションにクライアントIDが表示されることに注意してください。アプリケーションと統合するには、このIDを接続設定の一部として使用します。モバイル・アプリケーションはモバイル・デバイスで実行されるため、このタイプのアプリケーションにはクライアント・シークレットが生成されません。