IBM Cloud Docs
トークンの検証

トークンの検証

トークン検証は、最近のアプリ開発において重要な部分になっています。 トークンを検証することで、無許可ユーザーからアプリや API を保護できます。IBM Cloud® App ID は、アクセス・トークンと ID トークンを使用して、アクセス権限を付与する前に必ずユーザーまたはアプリを認証します。 App ID が提供するいずれかの SDK を使用している場合は、トークンの取得と検証の両方が自動的に行われます。

App ID でのトークンの使用方法について詳しくは、トークンについてを参照してください。

トークンは、個人が本人であることを検証するために使用されます。 また、指定された期間、ユーザーが保持するアクセス許可が正しいことを確認します。 ユーザーがアプリケーションにサインインしてトークンが発行されると、アプリでは、アクセス権限を付与する前にそのユーザーを検証する必要があります。

App ID に該当の SDK がない言語で作業している場合はどうすればよいですか?

次の 3 つのオプションがあります。

  • App ID API を使用して作業する
  • 独自の検証ロジックを実装する
  • OIDC 準拠のオープン・ソース SDK を使用する

App ID API の使用

イントロスペクションを使用することにより、App ID を使用してトークンを検証できます。

  1. /introspect API エンドポイントに POST 要求を送信してトークンを検証します。 要求には、トークンと、クライアント ID およびシークレットを入れた基本許可ヘッダーを含める必要があります。

    要求例:

    POST /oauth/v4/<tenantID>/introspect HTTP/1.1
    Host: us-south.appid.cloud.ibm.com
    Content-Type: application/x-www-form-urlencoded
    Authorization: Basic jdFlUaGlZUzAwTW0Tjk15TmpFMw==
    Cache-Control: no-cache
    
    token=XXXXX.YYYYY.ZZZZZ
    
  2. サーバーは、トークンの有効期限と署名を検査し、トークンがアクティブか非アクティブかを示す JSON オブジェクトを返します。

    応答の例:

    {
    "active": true
    }
    

トークンの手動検証

トークンを構文解析し、トークンの署名を検証し、トークンに保管されているクレームを検証することによって、トークンをローカルで検証できます。

  1. トークンを解析します。 JSONウェブトークン(JWT )は、情報を安全に渡す標準的な方法です。 これはヘッダー、ペイロード、および署名という 3 つの主要部分で構成されています。 これらは base64URL でエンコードされ、ドット (.) で区切られます。トークンの解析に使用できる任意の base64URL デコーダーを使用できます。 あるいは、トークンをパースするために 、リストにあるライブラリのどれかを使うこともできる。

    エンコードされたトークンの例:

    eyJhbGciOiJSUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJhMmszIn0
    .eyJpc3MiOiJhcHBpZC1vYXV0aCIsImF1ZCI6ImFiYzEyMyIsImV4cCI6MTU2NDU2Nn0
    .IycnAGUmMHzpTWbe-qaRsx0B4Zi-SVav710Fb_8CTCQvLrHX9d42WuCZ5bW
    d-ikgEsf6waQxeBfhfwYxwHN87LZupApagVMZtylVAnXhG1pHu_32wbZsPvg6QjzNO
    j6ys2Lfl3qfb5Qrp9u4IsZltKPEN8HdfeOcKXxpw6UqP-8
    

    デコードされたトークンの例:

    {
    "alg": "RS256",
    "typ": "JOSE",
    "kid": "a2k3",
    "iss": "https://us-south.appid.cloud.ibm.com/oauth/v4/39a37f57-a227-4bfe-a044-93b6e6050a61",
    "aud": "abc123",
    "exp": 1564566
    }
    
  2. /publickeys エンドポイント を呼び出して、公開鍵を取得します。 返される公開鍵は、 JSONウェブ鍵(JWK )としてフォーマットされる。

    要求例:

    GET /oauth/v4/<tenantID>/publickeys HTTP/1.1
    Host: us-south.appid.cloud.ibm.com
    Cache-Control: no-cache
    
  3. 後で使用できるように、鍵をアプリ・キャッシュに保管します。 鍵を保管すると、プロセスが高速化され、別の呼び出しが行われた場合のネットワーク遅延が防止されます。

  4. 公開鍵のパラメーターをインポートします。

    応答の例:

    {
    "keys": [
       {
          "kty": "RSA",
          "use": "sig",
          "n": "AsdaE",
          "e": "SDAasw",
          "kid": "ad123dCAz"
       }
    ]
    }
    
    公開鍵パラメーター
    パラメーター 説明
    kty 使用するアルゴリズムを定義します。
    use 鍵の目的を定義します。
    kid 鍵の固有 ID を定義します。
    その他 同様にインポートする必要のある、ご使用のアルゴリズムに固有の他のパラメーターも存在する可能性があります。
  5. トークンの署名を検査します。 トークン・ヘッダーには、トークンの署名に使用されたアルゴリズムと、対応する公開鍵の鍵 ID (つまり kid クレーム) が含まれます。 公開鍵は頻繁には変更されないため、公開鍵をアプリのキャッシュに入れて、時々リフレッシュすることができます。 キャッシュに入れられた鍵に kid クレームがない場合は、それらのトークンをローカル側で検証できます。

    1. アプリケーションで、着信トークン・ヘッダーの内容が公開鍵のパラメーターと一致することを検査します。
    2. 特に、同じアルゴリズムが使用されたことと、公開鍵キャッシュの中に、関連する鍵 ID を持つ鍵が含まれていることを検査します。
    3. ハッシュ値が PEM 形式の公開鍵の署名と同じであることを確認します。 ハッシュ値は、トークンのペイロードのヘッダーを結合してハッシュすることによって取得できます。 このプロセスの手動による実装は複雑になることがあるので、リストされているライブラリーのいずれかを使用して署名を検証すると役立つ場合があります。
  6. トークンに保管されているクレームを検証します。 今後の検査を検証するには、このリストを使用できます。

    検証されなければならないクレーム
    クレーム 説明
    iss 発行者は、App ID OAuth サーバーと同じでなければなりません。
    exp 現在時刻は有効期限時刻より前でなければなりません。
    aud オーディエンスには、アプリのクライアント ID が含まれている必要があります。
    tenant テナントには、アプリのテナント ID が含まれている必要があります。
    scope ユーザーに付与される許可のスコープ。 これはアクセス・トークンに固有のものです。