OpenID Connectの実装に関する注意事項
IBM® Verify セキュリティのベストプラクティスに従い、 OpenID Connectの実装におけるセキュリティの改善を継続しています。 以前のバージョンとの互換性は可能な限り維持されますが、セキュリティを強化するために一部の項目を変更する必要があります。
OpenID Connectの実装に関する変更点
- 一部のエラーメッセージは更新される場合がありますが、メッセージIDは変更されません。 レスポンスメッセージを読み取るロジックを含む処理がある場合は、代わりにメッセージIDを使用してください。
- 認証コードやトークンを取得するために認証エンドポイントにリクエストが送信されると、ユーザーはログインや多要素認証を行うためにリダイレクトされる場合があります。 ブラウザでは、この操作を行うと自動的にリダイレクトされます。 テスト自動化がこのフローに基づいて構築されている場合は、リダイレクトも自動的に追跡するようにしてください。
- スコープを返すエンドポイントの場合、スコープを返さない場合や、スコープとして空の文字列を返す場合は、同じように扱われます。
- JSON文字列内のスラッシュ(/)はエスケープされていない可能性があります。 JSONパーサーが両方の要件を満たしていることを確認してください。
- APIの利用権限は、ユーザーの同意を求める画面に表示されなくなりました。 そのクライアント用に生成されたトークンには、引き続きAPI利用権限が付与されます。
- この仕様では
redirect_uri、がhostnameまたはIPループバックリテラルであるlocalhost場合に限り、でスキームhttpを使用することが許可されています。 OpenID を参照してください。「Connect Core」の 1.0: セクション 3.1.2.1。 認証リクエスト。 - クエリパラメータの順序は、必ずしも一定であるとは限りません。 クエリパラメータを処理する際は、適切なライブラリを使用するか、順序に関係なくパラメータを検出できる堅牢
regexな処理を実装してください。
OpenID Connectの実装における今後の変更点
以下の項目については、直ちに変更を行う必要はありません。 ただし、 OpenID Connectの導入がベストプラクティスに沿ったものとなり、将来の変更にも対応できるよう、これらの項目を変更することを強くお勧めします。
- 一般的に、POSTリクエストでは、クエリパラメータではなくリクエスト本文にパラメータを含める方が安全です。
- この
nonceパラメータは、攻撃者に推測されないようにするため、暗号学的にランダムな値でなければなりません。 十分な長さがあり、ランダムであることを確認してください。 「Nonceの実装に関する注意事項」 を参照してください。 8文字以上を入力することをお勧めします。 - 認証サーバー(IBM Verify)は、任意の長さの認証コードとトークンを生成しますが、セキュリティ上の理由から、将来的にこれらが変更される可能性があります。 トークンを保存する際は、トークンの長さに少なくとも1024文字を確保してください。 IDトークンやJWT形式のアクセストークンなど、JWT形式のトークンの長さは、JWTの内容によって異なります。 JWTの内容は、より多くの属性がマッピングされるにつれて拡張されます。
- ベアラー・トークンのトークン種別は大文字小文字を区別しません。例えば、「Bearer」や「bearer」などです。 この値に対して、大文字と小文字を区別する検証を行わないでください。
- リフレッシュトークンのフローが実行されると、新しいIDトークンには元のノンスが含まれなくなります。 元のフローから返される は
nonce、認証リクエストに対するリプレイ攻撃を緩和するために使用されますが、リフレッシュトークンフローにおけるその後のトークンリクエストでは、この緩和策は必要ありません。 nonceと同様に、PKCEコード検証値は、暗号学的にランダムな値であり、推測不可能なものでなければなりません。 仕様では、コード検証ツールの長さは43文字以上であることが求められています。 RFC 7636 を参照してください。- この
stateパラメータを使用し、検証可能な推測不可能な値に設定することで、クロスサイトリクエストフォージェリを防止します。 たとえば、ユーザーエージェントの認証に使用されるセッション Cookie のハッシュを生成します。 RFC 6749を参照のこと。 8文字以上を入力することをお勧めします。 - 「audience」の
aud値は、文字列または配列です。 特に、対象となる値が1つしかない場合は、文字列、または文字列が1つ入った配列となります。 - クライアント認証情報によるアクセス許可タイプは、マシン間アクセス用のアクセストークンを生成することを目的としています。 このグラントタイプでは、IDトークンが生成されたり、アクセストークンを使用してエンドポイントに
userinfoアクセスしたりすることはできない点にご注意ください。 - IDトークン内の(タイプ)ヘッダーパラメータは
typ省略可能です。 信頼側は、IDトークンにヘッダーパラメータが含まれているtypことを想定してはならない。