認証の管理

ID プロバイダー (IdP) は、認証によって、モバイル・アプリと Web アプリのセキュリティーを強化します。 IBM Cloud® App ID では、1 つ以上の ID プロバイダーを構成して、ユーザーのカスタム・サインイン操作環境を作成できます。

App ID は、OpenID Connect や SAML などのさまざまなプロトコルを使用して ID プロバイダーと対話します。例えば、OpenID Connect は、Facebook や Google などの多くのソーシャル・プロバイダーで使用されているプロトコルです。 Azure Active Directory や Active Directory Federation Service などのエンタープライズ・プロバイダは、一般に SAML を ID プロトコルとして使用する。クラウドディレクトリの場合、SCIM が身元情報を検証する。

ソーシャル ID プロバイダーまたはエンタープライズ ID プロバイダーを使用する場合、App ID はユーザー・アカウント情報を読み取ります。このサービスには情報への書き込み権限がないため、ユーザーは選択した ID プロバイダーを使用して、パスワードのリセットなどのアクションを実行する必要があります。例えば、ユーザーが Facebook を使用してアプリにサインインした後にパスワードを変更する場合は、www.facebook.com にアクセスしてそれを行う必要があります。 {: note}a

Cloud Directoryを使用する場合、App ID が ID プロバイダーになります。このサービスは、レジストリーを使用してユーザー ID を検証します。 App ID は ID プロバイダーであるため、ユーザーは、パスワードのリセットなどの拡張機能をアプリ内で直接利用できます。

アプリケーション識別の作業を行いますか? アプリケーション識別を参照してください。

App ID で使用するために構成できる ID プロバイダーは、いくつかあります。次の表を参照して、オプションを確認してください。

アイデンティティ・プロバイダのオプション
ID プロバイダー	タイプ	説明
Cloud Directory	管理対象レジストリー	独自のユーザー・レジストリーをクラウドで保守できます。ユーザーがアプリに登録すると、ユーザーのディレクトリーに追加されます。このオプションにより、ユーザーはアプリ内で自分のアカウントをより自由に管理できます。
SAML	Enterprise	ユーザー用のシングル・サインオン操作環境を作成できます。
Facebook	ソーシャル	ユーザーは、Facebook の資格情報を使用してアプリにサインインできます。
Google+	ソーシャル	ユーザーは、Google の資格情報を使用してアプリにサインインできます。
カスタム	カスタム	提供されているどのオプションもお客様固有のニーズに合わない場合は、App ID で作業するための独自の識別フローを構成できます。

プロバイダーの管理

ID プロバイダーは、ユーザー、機能 ID、アプリケーションなどのエンティティーに関する情報を作成および管理します。このプロバイダーは、パスワードなどの資格情報を使用してエンティティーの同一性を検証します。そして、IdP が ID 情報を App ID に返すと、App ID がユーザーを許可し、アプリへのアクセス権限を付与します。

サービス・ダッシュボードにナビゲートします。
ナビゲーションの**「ID プロバイダー」セクションで、「管理」**ページを選択します。
**「ID プロバイダー」タブで、使用するプロバイダーを「オン」**に設定します。
オプション:「匿名ユーザー (Anonymous users)」をオフにするか、それともデフォルト (「オン」) のままにするかを決定します。 **「オン」**に設定すると、アプリとの対話を開始した時点から、ユーザー属性がユーザーに関連付けられます。識別されたユーザーになるための手順について詳しくは、段階的な認証を参照してください。

App ID には、Facebook と Google+ の初期セットアップに役立つデフォルトの資格情報が用意されています。資格情報の使用は、1 インスタンスあたり毎日 20 回に制限されています。これらは IBM の資格情報なので、これを使用するのは開発のときだけにしてください。アプリを公開する前に、自分の資格情報になるように構成を更新してください。

リダイレクト URI の追加

アプリケーションは、認証のためにユーザーを App ID にリダイレクトします。認証が完了すると、App ID はユーザーをアプリケーションにリダイレクトして戻します。 App ID がユーザーをアプリにリダイレクトできるようにするには、リダイレクト URI を登録する必要があります。サインイン・フローで、App ID は、許可ワークフローにクライアントが参加することを許可する前に、URI を検証します。これは、フィッシング攻撃と認可コード漏えいを防ぐのに役立ちます。 URI を登録することで、その URI が信頼できる URI であり、ユーザーをリダイレクトしてよいことを App ID に認識させます。

**「認証設定 (Authentication Settings)」**をクリックすると、URI とトークンの構成オプションが表示されます。

**「Web リダイレクト URI の追加」**フィールドに URI を入力します。リダイレクトを成功させるには、どの URI も http:// または https:// で始め、照会パラメーターを含めた絶対パスを指定しなければなりません。 URI の形式設定については、次の表にあるいくつかの例を確認してください。

WebリダイレクトURIの例
タイプ	サンプル URI
カスタム・ドメイン	`https://mydomain.net/myapp2path/appid_callback`
Ingress サブドメイン	`https://mycluster.us-south.containers.appdomain.cloud/myapp1path/appid_callback`
ワイルドカード	`https://mydomain.net/` 注: ワイルドカードを実稼働アプリで使用することは推奨されません。*

常に暗号化を使用して HTTP を避けることをお勧めします。

**「Web リダイレクト URI の追加 (Add web redirect URI's)」**ボックス内の + 記号をクリックします。

信頼できるアプリケーションの URI だけを登録するようにしてください。
考えられる URI をすべてリストに追加するまで、ステップ 1 から 3 を繰り返します。

トークン存続期間の構成

App ID はトークンを使用してユーザーの識別とリソースの保護を行います。トークンの存続期間を設定して、アプリケーションの要件に合わせて構成を調整できます。トークンの存続時間は、ユーザーがサインインするたびに始まります。例えば、リフレッシュ・トークン存続時間を 10 日に設定したとします。ユーザーが初めてサインインすると、アクセス・トークンとリフレッシュ・トークンが作成されます。 3 日後にユーザーがアプリを再度使用する場合は、再度サインインする必要はありません。しかし、ユーザーが初回のサインインから 12 日間待ってからアプリを再度使用する場合は、再度サインインする必要があります。トークンについて詳しくは、トークンについてを確認してください。

トークンの有効期限を設定すると、その値は、使用可能にしたすべてのプロバイダーに適用されます。トークンをさらにカスタマイズしたい場合は、カスタム・クレームをマップする API を呼び出して実行時にユーザー情報を提供する方法を試してください。 API を使用する場合、構成するカスタマイズ時間は異なります。

サービス・ダッシュボードの**「認証の管理 (Manage Authentication)」>「認証設定 (Authentication settings)」**タブに進みます。
**「サインイン有効期限 (Sign-in Expiration)」タブで、リフレッシュ・トークンを「有効」**に切り替えます。

以下の表に示すように、トークン・タイプごとに、各トークン・タイプの値を追加します。

トークンの種類とカスタマイズ・オプション
トークンのタイプ	説明	デフォルト	オプション
アクセス	アクセス・トークンが有効である時間の長さ。値が小さいほど、トークンの盗用に対する保護を強化できます。	60 分間	5 から 1440 までの範囲の任意の値
リフレッシュ	リフレッシュ・トークンが有効である時間の長さ。数値が小さいほど、ユーザーはより頻繁にサインインしなければならないことになります。	30 日間	1 から 90 までの範囲の任意の値
匿名	匿名トークンが有効である時間の長さ。匿名トークンは、ユーザーがアプリとのやり取りを開始した瞬間に割り当てられます。ユーザーがサインインすると、匿名トークン内の情報が、そのユーザーに関連付けられたトークンに転送されます。	30 日間	1 から 90 までの範囲の任意の値

識別トークンは、アクセス・トークンに設定した時間の長さと一致するように自動的に構成されます。別の値にすることはできません。

保存をクリックします。