OpenID コネクト実施上の注意

IBM® Verify セキュリティのベストプラクティスに従い、 Connectの実装にセキュリティの改善を続けている。 OpenID 以前のバージョンとの互換性は可能な限り維持されるが、セキュリティを向上させるためにいくつかの項目を変更しなければならない。

OpenID コネクト導入に伴う変更点

  • いくつかのエラーメッセージは更新されるかもしれませんが、メッセージIDは変わりません。 応答メッセージを読み取るロジックを持つプロセスがある場合は、メッセージIDを代わりに使用してください。
  • 認可コードやトークンを取得するために認可エンドポイントがヒットすると、ログインや多要素認証のためにユーザーをリダイレクトするかもしれません。 ブラウザでは、この操作の結果、いくつかの自動リダイレクトが発生します。 このフローを中心にテスト自動化を構築する場合は、リダイレクトも自動的にフォローするようにしてください。
  • スコープを返すエンドポイントでは、スコープを返さないことも、スコープに対して空文字列を返すことも、同じように扱われます。
  • JSON文字列内のフォワードスラッシュ（/）がエスケープされない場合がある。 JSONパーサーが両方に対応していることを確認してください。
  • APIエンタイトルメントがユーザーの同意プロンプトに表示されなくなった。 API権限は、そのクライアント用に生成されたトークンに付与されたままである。
  • この仕様では、 hostname が localhost またはIPループバックリテラルの場合のみ、 redirect_uri で http スキームを使用することができる。 参照 OpenID コネクト・コア 1.0: セクション 3.1.2.1. 認証リクエスト.
  • クエリーパラメーターは、常に同じ順序で並べられるとは限らない。 クエリ・パラメータを処理するときは、適切なライブラリを使用するか、順序に関係なくパラメータを見つけることができる堅牢な regex 。

OpenID コネクト導入に伴う今後の変更点

以下の項目については、すぐに変更する必要はありません。 しかし、 OpenID Connectの実装がベストプラクティスに従い、将来的な変更にも対応できるように、これらの項目を変更することを強くお勧めします。
  • 一般的にPOSTリクエストでは、クエリパラメータではなくリクエストボディにパラメータを持つ方がより安全です。
  • nonce パラメーターは、攻撃者が推測できないように暗号化されたランダムな値でなければならない。 十分に長く、ランダムであることを確認する。 Nonce Implementation Notes を参照のこと。 8文字以上を推奨。
  • 認証サーバー(IBM Verify)は、認証コードとトークンを生成する。トークンの長さは任意であり、セキュリティ上の理由から将来変更される可能性がある。 トークンを保存する場合、トークンの長さは少なくとも1024文字にしてください。 IDトークンやJWT形式のアクセストークンのようなJWT形式のトークンの長さは、JWTの内容に依存する。 より多くの属性がマッピングされると、JWTコンテンツは拡張される。
  • ベアラ・トークンのトークン・タイプは、"Bearer "または "bearer "のように、大文字と小文字を区別しません。 この値の大文字小文字を区別するバリデーションは使用しないでください。
  • リフレッシュ・トークン・フローが実行されると、新しい ID トークンは元の nonce を持たない。 元のフローから返された nonce は、認可リクエストのリプレイ攻撃を緩和するために使用され、この緩和は、リフレッシュトークンフローの後続のトークン要求には必要ない。
  • nonce と同様に、PKCEコード検証子は暗号学的にランダムな値であり、推測不可能である必要がある。 この仕様では、コード・ベリファイアは43文字以上でなければならない。 RFC 7636を参照のこと。
  • state パラメータを使用して、検証可能な推測不可能な値にすることで、クロスサイトリクエストフォージェリを防ぎます。 例えば、ユーザーエージェントの認証に使われるセッションクッキーのハッシュを生成する。 RFC 6749を参照のこと。 8文字以上を推奨。
  • aud オーディエンスの値は文字列または配列である。 特に、観客の値が1つしか存在しない場合は、文字列または1つの文字列を含む配列にすることができる。
  • クライアント・クレデンシャル付与タイプは、マシン間アクセス用のアクセストークンを生成するためのものである。 このグラント・タイプが ID トークンを生成したり、アクセストークンを使用して userinfo エンドポイントにアクセスできることを期待しないでください。
  • IDトークンの typ (type)ヘッダーパラメータはオプションである。 依拠当事者は、IDトークンに typ ヘッダーパラメータを期待してはならない。