OpenID Connectとは？『仕組み』や『OAuthとの違い』などを解説！

この記事では『OpenID Connect』について、

• OpenID Connectとは
• OpenID Connectの身近な例
• OpenID Connectの仕組み
• OAuthの脆弱性とOpenID Connectによる解決
• OAuthとOpenID Connectの違い

などを図を用いて分かりやすく説明するように心掛けています。ご参考になれば幸いです。

OpenID Connectとは

OpenID Connectは、OAuth2.0を基本にして、認証ができるようになったプロトコルです。OpenID Connectにより、認証を他のWebサービスが代わりに行うことで、Webサービス間でID連携をすることができるようになります。

OpenID Connectを利用している身近な例としては、「GoogleのアカウントやLINEのアカウントを使用して、複数のWebサービスにサインインする」などがあります。以前はそれぞれのWebサービスでIDやパスワード等の入力をして認証が必要でした。しかし、OpenID Connectのおかげで、認証をGoogleやLINE等が代わりに行うことができるので、それぞれのWebサービスで必要だったIDやパスワード等の入力を省略することができるようになります。その結果、それぞれのWebサービスでIDやパスワードを管理する必要がなくなるし、会員登録も簡単にすることができます。このような「1つの認証で、複数のWebサービスにログインできるようにする仕組み」を、「シングル・サインオン(SSO: Single Sign On)」といいます。

OAuthは認可を実現するプロトコルですが、OpenID Connectは認証を実現するプロトコルです。OAuth はアクセストークンを使用して認可を行っています。一方、OpenID Connectでは、アクセストークンに加えて、IDトークンも使用することで、認証が可能となっています。

IDトークンはアクセストークンとは異なり、「認証されたユーザの属性情報(氏名、性別、住所、メールアドレスなど)」「いつ認証されたのか」「どのサーバで認証されたのか」「誰が認証されたのか」「有効期限」などの情報を含んでおり、かつ署名されているため改ざんができない(改ざんを検知できる)ようになっています。このIDトークンを使用することで、異なるWebサービス間でも、共通のIDやパスワードを取り扱うことができます。

OpenID Connectの「ロール(登場人物)」と「仕組み」

次に、OpenID Connectの仕組みについて説明します。OpenID Connectには3つのロール(登場人物)がいますので、そのロール(登場人物)についてまず説明します。

OpenID Connectのロール(登場人物)

OpenID Connectには下記に示す3つのロール(登場人物)がいます。

• エンドユーザー(End User)
• オープンIDプロバイダー、IDプロバイダー(IdP: Identity Provider)
• リライングパーティ(RP: Relying Party)

次に各ロール(登場人物)について順番に説明します。

エンドユーザー(End User)

サインインしてWebサービスを利用しようとしているユーザーです。認証を受ける対称です(だいたい人間です)。OAuthでは「リソースオーナー(RO: Resource Owner)」に対応しています。

オープンIDプロバイダー、IDプロバイダー(IdP: Identity Provider)

ユーザーの認証を行うWebサービスです。ユーザー認証情報(パスワードなど)を管理したり、ユーザー属性情報(氏名、性別、住所、メールアドレスなど)を保持しています。IDプロバイダーは認可サーバの役割を兼ね備えることができます。OAuthでは「認可サーバ(AS: Authorization Server)」に対応しています。

リライングパーティ(RP: Relying Party)

エンドユーザーのユーザー属性情報を要求するために、IDプロパイダにアクセスするWebサービスです。エンドユーザーからのリクエストに応じて、IDプロバイダーによる認証情報を信頼(Rely)して、Webサービスへのアクセスを許可しています。つまり、リライングパーティはIDプロバイダーに認証を委譲しています。OAuthでは「クライアント(OAuth Client)」に対応しています。

OpenID Connectの仕組み

OpenID Connectの仕組みについて説明します。

OpenID ConnectのID連携には様々なフロータイプがありますが、ここではAuthorization Code Flowと呼ばれるフロータイプについて説明します。

一例として、IDプロバイダーをGoogleとして、Googleが保持しているユーザー属性情報(氏名、性別、住所、メールアドレスなど)をリライングパーティ(アプリケーション)が利用する場合を考えてみましょう。

リライングパーティにアクセスして認証開始

エンドユーザーがリライングパーティのログインページにアクセスします。

OpenID Connectのトリガーはリライングパーティ側で「Googleでログイン」といったリンクなどをクリックした時です。上の図では、このリライングパーティは、FacebookやTwitterなどの様々なWebサービスとID連携することができることが分かります。ここでは、GoogleとID連携したいので、「Googleでログイン」のリンクをクリックします。リンクをクリックすると、OpenID Connectの処理が始まり、リライングパーティとIDプロバイダー(Google)がID連携するための手続きが開始します。

認証要求・認証リクエスト

エンドユーザーからIDプロバイダー(Google)へのID連携の要求を受けたリライングパーティは、IDプロバイダー(Google)の認可エンドポイントにリダイレクトさせます。IDプロバイダー(Google)にリダイレクトすることによって、画面(ブラウザなど)に表示されている画面がIDプロバイダー(Google)が提示している画面に切り替わります。

リダイレクトの際、URLのクエリパラメータにクライアントID (client_id)を付与しています。

ログイン画面・連携同意画面の表示

IDプロバイダー(Google)はログイン画面やID連携同意画面をエンドユーザーに提示します。この認証画面では、IDプロバイダー(Google)はエンドユーザーに対して、リライングパーティが要求しているエンドユーザーの取得したい情報を確認しています。例えば、上図の画面ではリライングパーティがIDプロバイダー(Google)が保持している「生年月日」や「住所」などの情報を取得してもよいかを確認しています。

リライングパーティは色々なWebサービス(例えば、amazonやLINEなど)とも連携することができますが、ここで、GoogleとのID連携を許可してもよいかと確認できたのは、URLのクエリパラメータで渡されたクライアントID(client_id)で判断しているからです。また、上図では、ユーザー認証とID連携同意をまとめて行うページが返されていますが、ページ遷移を複数回伴っている場合もあります。

ログイン・連携同意

エンドユーザーは必要に応じて、IDやパスワードなどを入力して、ログインします(認証)。この認証は、IDプロバイダー(Google)が認証処理を進めるために必要な認証であり、リライングパーティは認証情報そのものはおろか、認証情報がやりとりされていることすら知りません。また、エンドユーザーの取得したい情報を確認し、問題なければ許可します。

認可コードを発行

IDプロバイダー(Google)で認証が正しく行われると、認可コード(IDプロバイダーへのアクセスを許可したことを示すコード)を発行し、リライングパーティのリダイレクトURLにリダイレクトします。そのため、この処理はエンドユーザーには見えず、システム間で行われます。

リライングパーティのURLにリダイレクトすることによって、画面(ブラウザなど)に表示されている画面がリライングパーティが提示している画面に切り替わります。認可コードはURLのクエリパラメーターに「code=…」という形式で設定して、リライングパーティにリダイレクトしています。

認可コードを提示して、アクセストークンとIDトークンを要求

認可コードを受け取ったリライングパーティは、IDプロバイダー(Google)のトークンエンドポイントに対して、認可コードを提示して、「IDプロバイダー(Google)が保持している情報にアクセスするために必要なアクセストークン」と「エンドユーザーを認証するために必要なIDトークン」を要求します。

アクセストークンとIDトークンを発行

IDプロバイダー(Google)では、リライングパーティから送られた認可コードの有効性を検証しています。「IDプロバイダー(Google)が発行した認可コード」と「リライングパーティから送られた認可コード」が一定しているか、有効期限は切れていないか等を確認し、問題がなければ、アクセストークンとIDトークンを生成し、リライングパーティに発行します。

アクセストークンを提示して、リソース要求

リライングパーティはIDトークンを検証します。問題がなければ、IDプロバイダー(Google)によりエンドユーザーが認証されたことが確認できたことになります。次に、アクセストークンをIDプロバイダー(Google)のユーザー情報エンドポイント(UserInfo エンドポイント)に提示して、リソース(エンドユーザーの情報)を要求します。

リライングパーティに対してリソース応答

アクセストークンを受けとったIDプロバイダー(Google)は、アクセストークンの有効性を検証し、問題がなければ、エンドユーザーの情報をリライングパーティに提供します。

エンドユーザーに対してリソース応答

リライングパーティはエンドユーザーに対して、リソースを含む画面をレスポンスします。なお、ユーザー情報を受け取った後にその情報をどう扱うかはリライングパーティの実装次第です。例えば、エンドユーザーをログイン状態にし、リライングパーティのトップページやどこかのページに遷移させることができます。

OAuthの脆弱性とOpenID Connectによる解決

OAuthは認可プロトコルであり、認証プロトコルではありません。認可のプロトコルであるOAuthを認証に間違えて使うと、なりすましの脆弱性が生じる可能性があります。

そのため、認証にはOpenID Connectを使用するのが適切です。OpenID ConnectはOAuth 2.0をベースにしており、認証に特化したプロトコルです。OpenID Connectを使用することで、認証情報の改ざんやなりすましを防ぐことができます。

ここで、一例として、OAuthを認証に用いた場合を考えてみましょう。例えば、悪人Aが「偽物のWebサービスA」を作ったとします。その「偽物のWebサービスA」では「WebサービスB(例えばGoogleなど)」とID連携できるようになっている場合を考えてみましょう。

Bさんが間違えて「偽物のWebサービスA」のログインページにアクセスして「Googleでログイン」のリンクをクリックした場合、「WebサービスB(Google)」から「偽物のWebサービスA」にアクセストークンが発行されます。すると、Bさんは「偽物のWebサービスA」にログインすることができます。しかし、この時、「偽物のWebサービスA」を作っている悪人AはBさんのアクセストークンを盗むことができます。

次に、悪人Aは「本当のWebサービスA」のログインページにアクセスし、「Googleでログイン」のリンクをクリックします。この時にBさんのアクセストークンを利用すると、悪人AはBさんになりすまして、ログインすることができてしまいます。

これは、OAuthが認可の仕組みだからです。アクセストークンには「WebサービスA」が本物なのか偽物なのかを確認するための仕組みがありません。

認証にOAuthではなくOpenID Connectを使っていれば、悪人A にIDトークンとアクセストークンが盗まれても、IDトークンによって、「これは偽物のWebサービスAに対して発行されたものだ！」とアクセストークンの発行先が特定できるので、「本当のWebサービスA」では使うことができません。その結果、悪人AはBさんになりすまして、「本当のWebサービスA」にログインすることができなくなります。つまり、なりすましを防ぐことができます。

OAuthとOpenID Connectの違い

OAuthとOpenID Connectの主な違いについて下記にまとめます。

• プロトコルが違う
  • OAuthは認可のプロトコルですが、OpenID Connectは認証のプロトコルです。
• IDトークンを発行するかが違う
  • OAuthはアクセストークンを発行しますが、OpenID Connectはアクセストークンに加えて、IDトークンも発行します。
• 「グラント」か「フロー」かが違う
  • OAuth 2.0では、トークンを発行する手段として様々なタイプがあり、「○○グラント」と呼びます。例えば、「Authorization Code Grant」、「Implicit Grant」、「Resource Owner Password Credentials Grant」、「Client Credentials Grant」などがあります。
  • 一方、OpenID Connectでは、トークンを発行する手段のタイプを「○○フロー」と呼びますが、これはOAuth 2.0の「○○グラント」とほぼ同じ意味です。OpenID Connectでの主なフローには、「Authorization Code Flow」、「Implicit Flow」、「Hybrid Flow」があります。
• ロール(登場人物)の用語が異なる
  • OAuthとOpenID Connectのロール(登場人物)の用語を下記に示します。

本記事のまとめ

この記事では『OpenID Connect』について、以下の内容を説明しました。

• OpenID Connectとは
• OpenID Connectの身近な例
• OpenID Connectの仕組み
• OAuthの脆弱性とOpenID Connectによる解決
• OAuthとOpenID Connectの違い

お読み頂きありがとうございました。