IBM Cloud Docs
テクノロジー

テクノロジー

許可と認証の違いは間違えやすいので、 注意が必要です。 以下の情報を参照して、IBM Cloud® App ID を利用するときに使用される特定の用語、プロセス、テクノロジーについて理解してください。

許可および認証の基本概念について詳しく知りたい場合は、 以下をご覧ください。 次のビデオで、OAuth 2.0、付与タイプ、OIDC などについて説明しています。

OAuth 2

OAuth2.0は、アプリの認可を提供するために使用されるオープンスタンダードのプロトコルです。

Open ID Connect (OIDC)

OIDC は、OAuth 2 と連携する認証層です。 OIDC と App ID を一緒に使用すると、OAuth エンドポイントを構成する際にご使用のアプリケーション資格情報が役立ちます。 SDK を使用する場合、エンドポイント URL は自動的に作成されます。 しかし、サービス資格情報を使用して、URL を自分で作成することもできます。 URL には、App ID service endpoint + "/oauth/v4" + /tenantID の形式を使用します。

例:

{
  "clientId": "7eba72ef-b913-47b0-b3b6-54358bb69035",
  "tenantId": "8f5aa500-357e-443a-aab6-bf878f852b5a",
  "secret": "OWEzZGM4M2UtZjhlYS00MDI2LTkwNGItNDJmYzViMmU2YzIz",
  "name": "testing",
  "oAuthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a",
  "profilesUrl": "https://us-south.appid.cloud.ibm.com",
  "discoveryEndpoint": "https://us-south.appid.ibm.cloud.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a/.well-known/openid-configuration"
}

この例の場合、URL は https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a になります。 これに、要求先のエンドポイントを付加します。 次の表を参照して、いくつかのエンドポイントの例を確認してください。

エンドポイントの例
エンドポイント フォーマット
許可 <oauthServerUrl>/authorization
トークン <oauthServerUrl>/token
ユーザー情報 <oauthServerUrl>/userinfo
JWKS <oauthServerUrl>/publickeys

SDK を使用する場合、エンドポイント URL は自動的に作成されます。

トークン

サービスは、3 種類の異なるトークンを使用します。 トークンの設定は、App ID ダッシュボードの**「ID プロバイダー」>「管理」**で行います。 トークンおよび App ID でトークンを使用する方法について詳しくは、トークンの管理を参照してください。

  • アクセス・トークン: 許可証に相当します。これにより、保護されている バックエンド・リソースとの通信が可能になります。 リソースは、App ID で設定する許可フィルターによって保護されます。

  • 識別トークン: 認証書に相当します。ユーザーに関する情報が含まれています。

  • リフレッシュ・トークン: これにより、ユーザーの再認証を行わずに新規アクセス・トークンを取得できます。 リフレッシュ・トークンを使用すると、ユーザーの情報をアプリケーションに記憶させられるので、サインインした状態を保持することができます。

許可ヘッダー

App IDは ベアラートークンの仕様に準拠し、HTTP Authorizationヘッダーとして送信されるアクセストークンとアイデンティティトークンの組み合わせを使用します。 許可ヘッダーは、空白文字で区切られた 3 つの部分で構成されます。 これらのトークンは base64 でエンコードされます。 識別トークンはオプションです。

例:

Authorization=Bearer <accessToken> [<idToken>]

API 戦略

API 戦略では、有効なアクセス・トークンを含む許可ヘッダーが要求に含まれていなければなりません。 識別トークンも要求に含めることができますが、これは必須ではありません。 トークンが無効または期限切れの場合、API 戦略は、次の HTTP ヘッダーを含む HTTP 401 エラーを返します。

Www-Authenticate=Bearer scope="<scope>" error="<error>"

要求から有効なトークンが返された場合、制御が次のミドルウェアに渡され、appIdAuthorizationContext プロパティーが要求オブジェクト内に挿入されます。 このプロパティーには、元のアクセス・トークンと識別トークン、およびデコードされたペイロード情報が平文の JSON オブジェクトとして含まれます。

Web アプリ戦略

Web アプリ戦略は、保護リソースに対する無許可のアクセス試行を検出すると、ユーザーのブラウザーを認証ページ (App ID で提供可能) に自動的にリダイレクトします。 認証に成功すると、ユーザーは Web アプリのコールバック URL に返されます。 Web アプリ戦略は、アクセス・トークンと識別トークンを取得し、HTTP セッションの WebAppStrategy.AUTH_CONTEXT の下に保管します。 アクセス・トークンと識別トークンをアプリ・データベース内に保管するかどうかは、各ユーザーが決定します。

リダイレクト URI

App ID は、アプリとの対話後に、承認された完全修飾 URI のリストを使用してユーザーをリダイレクトします。 例えば、ユーザーが正常にサインインした場合、App ID は、アプリのホーム・ページまたは指定された別のページにユーザーをリダイレクトします。 URI の形式はアプリケーションによって変わる可能性があります。 詳しくは、リダイレクト URI の追加を確認してください。

JSON Web Key Set (JWKS)

JWKS は、暗号鍵のセットを表します。App ID は JWKS を使用して、サービスによって生成されたトークンの認証性を検証します。 鍵 ID を使用して署名を検証することで、信頼できるソース App ID によってトークンが発行されたことを確認できます。 また、トークン内の情報が変更されていないことも確認できます。