🔐

OpenID Connectについて勉強したのでまとめる

2023/01/04に公開約3,700字

はじめに

前回はOAuthについてまとめましたが、今回はOpenID Connectについてまとめてみたいと思います。

間違っているところがあればご指摘ください。

OpenID Connectとは

OpenID Connect は OAuth 2.0 認可プロセスを拡張し, 認証目的で利用できるようにする. 本拡張を利用する場合, Client は openid
 scope を指定して Authorization Request を送信する. 認証結果は ID Token (Section 2
 参照) と呼ばれる JSON Web Token (JWT)
 [JWT] として返される. OpenID Connect をサポートする OAuth 2.0 Authentication Server は, OpenID Provider (OP) とも呼ばれる. OpenID Connect を利用する OAuth 2.0 Client は Relying Party (RP) とも呼ばれる.
(OpenID Connect Core 1.0 incorporating errata set 1より引用)

つまり、OAuthの仕様を拡張し、アクセストークンに加えてIDトークンを発行することで、認証を行うことを可能にするためのものということができるかと思います。

OAuthはあくまで認可のための権限の移譲プロセスを定めた仕様であるため、本来、認証は仕様の範囲外です。しかしOAuthの「ユーザーIDとパスワードの管理を外部に任せられる」「ユーザー登録作業を簡略化できる」という利点から、OAuthによる認証というものが広まりました。

しかしながらOAuth認証は後述する問題点を孕んでいるため、OAuthの利点を享受しながら問題点を解消するための仕組みとして、OpenID Connectという仕様がOAuthの上に乗せる形で策定されたという経緯があります。

OAuthによる認証の問題点

まずOAuth認証とは何かというと、ユーザー情報(emailやuser_idなど)を対象リソースとしたOAuthによる認可プロセスを利用して取得したユーザー情報をもって認証を実行することです。

以下はインプリシットグラントタイプのOAuthのシーケンス図ですが、最後にリソースサーバーから返されるのがユーザー情報であれば、クライアントはこのユーザー情報をもって認証処理を実行することができます。

これの何が問題なのでしょうか。

アクセストークンにはクライアントを確認するための仕組みがありません。つまり誰宛に発行したアクセストークンなのかに関わらず、リソースサーバーはリソースを返してしまうということです。このため、クライアントが悪意あるクライアントであった場合、上記のフローで取得した他人のアクセストークンを使って、OAuth認証を採用している任意のサイトになりすましログインが可能となってしまいます。

OpenID ConnectではIDトークンというものを用いてこの問題に対処しています。次はIDトークンとは何かについてみていきましょう。

IDトークンとは

以下の情報および署名を含むトークン。JWT(JSON Web Tokenの略。詳細の説明は割愛)という形式でIDプロバイダ(OpenID Connectの登場人物の項を3章)から発行される。

IDトークンに含まれる情報(代表的なもののみ掲載。オプショナルな情報がこれら以外に付与されることもある)

  • iss
    Issuerの略。IDトークンの発行者
  • aud
    Audienceの略。IDトークンの発行を受けるクライアントIDが入る
  • sub
    Subjectの略。エンドユーザーの識別子。これを持ってエンドユーザーを識別できる
  • iat
    Issued Atの略。JWTの発行時間を表す。
  • exp
    Expiration timeの略。トークンの有効期限
  • nonce
    リプレイアタック防止のためのランダムな文字列

IDトークンには、ユーザー識別子、IDトークンの発行元、発行先などの情報が含まれるため、これらの情報が改竄されていないことを確認するために署名が含まれています。

OAuth認証と比べて、IDトークンの仕組みによって、ユーザー識別子、IDトークンの発行元、発行先などの情報が含まれているため、これらを適切に検証することでユーザーのなりすましを防ぐことができます。

OpenID Connectの登場人物

OpenID ConnectはOAuthの拡張仕様ですが、OAuthと登場人物の呼び方が異なります。

以下が対応表となります。

OAuth OpenID Connect
リソースオーナー エンドユーザー
クライアント リライングパーティ
認可サーバー IDプロバイダ
リソースサーバー UserInfoエンドポイント

OpenID Connectのフローの種類

  • 認可コードフロー
    OAuthの認可コードグラントタイプに対応するフロー。コンフィデンシャルなリライングパーティにおいて適応されるフロー
  • インプリシットフロー
    パブリッククライアント向けのフロー
  • ハイブリッドフロー
    ネイティブアプリにバックエンドサーバーがある場合など、パブリッククライアントとコンフィデンシャルクライアントの両方で構成されるリライングパーティにおいて適応されるフロー

シーケンス図

一番重要な認可コードフローのみ掲載します(以下の参考書籍に掲載されているものをdiagrams.netで写経してみたものになります。OAuthの記事でも書きましたが、この著者の方の本はどれも超勉強になるのでぜひ読んでみてください)

OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本 - Auth屋 - BOOTH

シーケンス図は以下の通りです。

OAuthの認可グラントタイプのシーケンス図とほぼ同じですが、トークンリクエストのレスポンスにIDトークンが含まれており、IDトークンの検証のプロセスが存在するのが大きな違いとなっています。

まとめ

OpenID Connectの仕様は奥が深く、全然表面の部分しか書けていないですが、さらに勉強を進めてまたの機会に深掘りした記事を書いていきたいと思います。

次回はセキュリティ的に重要な仕組みだが混乱しがちな、state, PKCE, nonce, c_hash, at_hashの違いについてまとめていきたいと思います。

参考

OpenID Connect Core 1.0 incorporating errata set 1

OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る - Qiita

IDトークンが分かれば OpenID Connect が分かる - Qiita

単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる

OAuth、OAuth認証、OpenID Connectの違いを整理して理解できる本 - Auth屋 - BOOTH

Discussion

ログインするとコメントできます