リダイレクト URI を許可リストに登録する必要があるのはなぜですか?

リダイレクト URI は、アプリケーションのコールバック・エンドポイントです。 許可リストに URI を登録すると、ユーザーをその場所に送信することを App ID に許可することになります。 実行時に、App ID は URI を許可リストに照らして検証してからユーザーをリダイレクトします。 このプロセスにより、フィッシング攻撃を防止し、攻撃者がユーザーのトークンにアクセスする可能性を抑えることができます。 リダイレクト URI について詳しくは、リダイレクト URI の追加を参照してください。

URL には照会パラメーターは含めないでください。 それらは検証プロセスで無視されます。 サンプル URL: http://host:[port]/path

暗号化は App ID でどのように機能しますか?

暗号化に関するよくある質問の答えは、以下の表を参照してください。

App ID はどのクロック同期を使用しますか?

App ID は、内部 NTP サーバー servertime.service.softlayer.com を使用する IBM Cloud で実行されます。

アプリケーションと App ID のタイム・ソースとの同期は、アプリケーションの実行に使用している環境に依存します。

• アプリケーションが IBM Cloud クラシック・インフラストラクチャーで実行されている場合、NTP サーバーを servertime.service.softlayer.com に設定します。
• アプリケーションが IBM Cloud VPC インフラストラクチャーで実行されている場合、NTP サーバーを time.adn.networklayer.com に設定します。
• アプリケーションが IBM Cloud で実行されていない場合は、これらのタイム・サーバーにアクセスすることができません。 この場合、NTP サーバーを time-a.nist.gov または time-b.nist.gov に設定します。

App ID と Keycloak の違いは何ですか?

App ID も Keycloak も、アプリケーションに認証を追加してサービスを保護するために使用できます。 2 つのオファリングの主な相違点は、パッケージ化の方法です。

Keycloak はソフトウェアとしてパッケージされています。つまり、ダウンロードした後は、開発者が製品の機能を保守する必要があります。 ホスティング、高可用性、コンプライアンス、バックアップ、DDoS 対策、ロード・バランシング、Web ファイアウォール、データベースなどには開発者が対応します。

App ID は、「as-a-Service」として提供されるフル・マネージドのオファリングです。 つまり、IBM がサービスの運用を管理し、準拠性、複数のゾーンでの可用性、SLA などに対応することを意味します。また、App ID では、Kubernetes Service、Cloud Functions、および Activity Tracker などのネイティブのランタイムやサービスが含まれている IBM Cloud Platform との統合エクスペリエンスも利用できます。

複数のアプリケーションで同じクライアント ID を使用できますか?

複数のアプリケーションで同じ資格情報を_can_使用することは技術的には可能ですが、いくつかの理由から、使用しないことを強くお勧めします。 その理由は何よりも、複数のアプリケーションで ID を共有すると、攻撃やセキュリティー侵害の種類にかかわらず、被害を受けるのが 1 つのアプリケーションではなく環境全体に及ぶためです。 例えば、3 つのアプリケーションで同じ ID を使用している場合に、いずれかのアプリケーションのセキュリティーが侵害されると、3 つのすべてのアプリが侵害されます。 攻撃者は、ご使用の任意のアプリケーションになりすますことができます。 2 番目の理由は、複数のアプリで同じクライアント ID を使用すると、アプリケーションを区別できないことです。 例えば、トークンの生成にどのアプリが使用されたかを見分けられません。

アプリケーションを更新して、データを失うことなく新しいサービス・インスタンスを使用するには、どうすればよいですか

情報を App ID インスタンス間でマイグレーションできます。

1. サービスのインスタンスを作成します。
2. GUI を使用して ID プロバイダー構成を複製します。
3. ユーザー・プロファイルをマイグレーションします。 既知のユーザーが 1 つの JSON オブジェクトとしてエクスポートされます。 匿名ユーザーはマイグレーションできません。 オブジェクト全体を新しいインスタンスにインポートすることも、複数のインスタンスがある場合はオブジェクトを分割してユーザーをインスタンスに合わせて分けることもできます。 Cloud Directory の場合は、 ユーザーのマイグレーションを参照してください。 フェデレーテッド ID プロバイダーの場合は、以下の手順を使用します。
4. 新しいサービス・インスタンスを呼び出すためのアプリケーション資格情報を作成します。
   1. サービス・ダッシュボードで、「アプリケーション」 タブにナビゲートします。
   2. **「アプリケーションの追加」をクリックし、アプリケーションの名前を指定します。 続いて、「保存」**をクリックします。
   3. 表の**「資格情報の表示」**をクリックし、出力をコピーします。
   4. 新しい資格情報をアプリケーションに貼り付けます。
5. URL を含む新しい資格情報を使用するようにアプリケーションを更新します。
6. 構成によっては、アプリケーションを再デプロイしたり、アンバインドしてから再バインドしたりする必要がある場合があります。

App ID を使用してログアウトを構成できますか?

アプリケーションの構成方法によっては、App ID を使用して、ユーザーがログアウト機能を容易に利用できるようにすることができます。 以下の表を参照して、ログアウトの機能が使用可能な場所を確認してください。

<script>
  var ticker = setInterval(tick, 1000);
  var counter = 5;
  function tick() {
    var timerDiv = document.getElementById("timer");
    if (counter > 0) {
      timerDiv.innerText = "Logged out. Redirecting back in " + (counter--) + " seconds.";
    } else {
      document.location = "./appid_logout";
    }
  } </script>
<iframe height="0" width="0" src="https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0"></iframe>