トークンの検証
トークン検証は、最近のアプリ開発において重要な部分になっています。 トークンを検証することで、無許可ユーザーからアプリや 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 を使用してトークンを検証できます。
-
/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
-
サーバーは、トークンの有効期限と署名を検査し、トークンがアクティブか非アクティブかを示す JSON オブジェクトを返します。
応答の例:
{ "active": true }
トークンの手動検証
トークンを構文解析し、トークンの署名を検証し、トークンに保管されているクレームを検証することによって、トークンをローカルで検証できます。
-
トークンを解析します。 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 }
-
/publickeys エンドポイント を呼び出して、公開鍵を取得します。 返される公開鍵は、 JSONウェブ鍵(JWK )としてフォーマットされる。
要求例:
GET /oauth/v4/<tenantID>/publickeys HTTP/1.1 Host: us-south.appid.cloud.ibm.com Cache-Control: no-cache
-
後で使用できるように、鍵をアプリ・キャッシュに保管します。 鍵を保管すると、プロセスが高速化され、別の呼び出しが行われた場合のネットワーク遅延が防止されます。
-
公開鍵のパラメーターをインポートします。
応答の例:
{ "keys": [ { "kty": "RSA", "use": "sig", "n": "AsdaE", "e": "SDAasw", "kid": "ad123dCAz" } ] }
公開鍵パラメーター パラメーター 説明 kty
使用するアルゴリズムを定義します。 use
鍵の目的を定義します。 kid
鍵の固有 ID を定義します。 その他 同様にインポートする必要のある、ご使用のアルゴリズムに固有の他のパラメーターも存在する可能性があります。 -
トークンの署名を検査します。 トークン・ヘッダーには、トークンの署名に使用されたアルゴリズムと、対応する公開鍵の鍵 ID (つまり
kid
クレーム) が含まれます。 公開鍵は頻繁には変更されないため、公開鍵をアプリのキャッシュに入れて、時々リフレッシュすることができます。 キャッシュに入れられた鍵にkid
クレームがない場合は、それらのトークンをローカル側で検証できます。- アプリケーションで、着信トークン・ヘッダーの内容が公開鍵のパラメーターと一致することを検査します。
- 特に、同じアルゴリズムが使用されたことと、公開鍵キャッシュの中に、関連する鍵 ID を持つ鍵が含まれていることを検査します。
- ハッシュ値が PEM 形式の公開鍵の署名と同じであることを確認します。 ハッシュ値は、トークンのペイロードのヘッダーを結合してハッシュすることによって取得できます。 このプロセスの手動による実装は複雑になることがあるので、リストされているライブラリーのいずれかを使用して署名を検証すると役立つ場合があります。
-
トークンに保管されているクレームを検証します。 今後の検査を検証するには、このリストを使用できます。
検証されなければならないクレーム クレーム 説明 iss
発行者は、App ID OAuth サーバーと同じでなければなりません。 exp
現在時刻は有効期限時刻より前でなければなりません。 aud
オーディエンスには、アプリのクライアント ID が含まれている必要があります。 tenant
テナントには、アプリのテナント ID が含まれている必要があります。 scope
ユーザーに付与される許可のスコープ。 これはアクセス・トークンに固有のものです。