OpenID Connectの仕組みやOAuthとの違いを分かりやすく解説

OpenID Connectの導入を検討しているものの、

・OpenID Connectの仕組みがわからない
・OAuthとの違いがわからない

と考える方は多いのではないでしょうか。そこでこの記事では、

・OpenID Connectの基礎知識
・OAuthとの違い
・OpenID Connectの認証までの流れ

についてわかりやすく解説します。

OpenID Connectとは？

OpenID Connect（OIDC）は、OAuth2.0（オーオース）を拡張し、システム間での認証を可能とする認証プロトコルです。OAuth2.0は認可のプロトコルであり、認証はできません。そこで、OAuth2.0を認証にも使えるように拡張したものがOpenID Connectです。

OpenID ConnectとOAuthは、どちらも国際的に標準化されています。OpenID ConnectはISO/IEC（国際標準化機構/国際電気標準会議）にて、2024年10月に9つの仕様が正式に発行されました。

OAuth2.0に関しても、IETF（インターネット技術の標準化を推進する組織団体）が作成する、インターネット技術の標準化や運用について記載された文書「RFC」の「RFC6749」などで、広く認められています。

OpenID Connectを利用すると、1つのログイン情報でほかのシステムにログインできるシングルサインオン（SSO）の実現が可能です。シングルサインオンを実現するための手段はいくつか存在しますが、そのなかでもOpenID Connectは一般的な手段となっています。

認証と認可

ここまで何度も「認証」と「認可」という言葉が出ていますが、一度言葉の意味をおさらいしておきましょう。

認証とは、本人確認のプロセスです。特定のアカウントにログインする際、そのアカウトの所有者とログインしようとするユーザーが、同一人物であることを確認します。

対して、認可とは、特定のコンテンツやシステムへのアクセス権を付与するプロセスです。主にロールベースで権限を設定し、本人確認は必ずしも必要としません。Webサービスなどへの登録時には、ユーザーの役割に応じて適切な権限が割り当てられます。

認証と認可は混同しがちですが、その役割や目的は大きく異なるものであるため、OpenID ConnectやOAuthを利用する際にはしっかりと区別して理解することが重要です。

　

OAuthとOpenID Connectの違い

OpenID ConnectとOAuthの最大の違いは、両者の主要な目的にあります。OAuthは認可を目的とし、リソースへのアクセス権限を管理するものです。対して、OpenID Connectは認可だけでなく認証まで対応できるようにしています。

仕組み上、OAuthでも認証は可能（OAuth認証）ですが、推奨されていません。その理由は、OAuthで発行されるアクセストークンはユーザーを確認する仕組み（本人確認）がなく、なりすましが可能であるからです。

OAuthは異なるサービス間での連携が考慮されておらず、現代の環境に適するように拡張されたものがOpenID Connectというわけです。

項目	OAuth	OpenID Connect
目的	認可	認証（+認可）
トークン	アクセストークン	アクセストークン、IDトークン
提供するもの	リソースアクセス	イベント情報、属性情報
利用者名称	Resource Owner	User
利用サービス名称	Client	Relying Party
認証サーバー名称	AuthZ/Resource Server	OpenID Provider

　

OAuthの仕組み

OAuthは以下のプロセスで認可を実行します。

1. Resource OwnerからClientに別サービスのリソース利用を要求する
2. ClientはAuthZ/Resource Serverにリダイレクトする
3. AuthZ/Resource ServerからResource Ownerにログイン要求する
4. Resource Ownerはログイン後、Clientからのリソースアクセスを許可する
5. AuthZ/Resource ServerからClientにリソースアクセス権限を提供（アクセストークン発行）する
6. アクセストークンを使ってClientはAuthZ/Resource Serverのリソースを利用できるようになる
7. Resource OwnerはClientから別サービスのリソースを利用できるようになる

上記の流れを図に表すと、以下のようになります。

例として、画像編集サービスをClient、ストレージサービスをAuthZ/Resource Serverとして考えるとわかりやすいでしょう。

ユーザーはどちらのサービスも利用しており、Resource Ownerとして画像編集サービスからストレージサービスに保存されている画像参照し、編集することができる、といったイメージです。

　

OpenID Connectの認証までの流れ

OpenID Connectの仕組み、及び認証までの流れは以下の通りです。

1. UserがRelying Partyの認証画面にアクセスする
2. Relying PartyはOpenID Providerにリダイレクトし、認証イベント情報を要求する
3. OpenID ProviderはUserにログイン要求する
4. UserはOpenID Providerにログイン後、Relying Partyへの属性情報提供を許可する
5. OpenID ProviderはRelying Partyへ各種トークンを提供
6. Relying Partyで認証情報を扱えるようになる
7. UserはRelying Partyにログインできるようになる

上記を図で表すと、以下のようになります。

OAuth2.0の図と比べると、非常によく似ていることがわかります。

OAuth2.0と大きく異なる点はIDトークンの有無です。OpenID Providerは認可サーバーを兼ねることが多く、IDトークンだけでなくアクセストークンも併せて発行することが多いです。OAuth2.0と異なり、IDトークンを発行することでID連携が実現できるようになっています。

　

シングルサインオンが実現する仕組み

シングルサインオンとは、一度ログインすれば、複数のサービスでログイン情報を使い回せる、というものです。何度もログイン情報を入力する手間を省くことができ、ユーザーにもメリットがあるシステムです。

ここでは、ユーザー「Taro」さんがサービスA・サービスBを利用する際のシングルサインオンの仕組みについて簡単に解説します。

なお、ここからの解説は、ユーザーのTaroさんが、事前にRelying PartyであるサービスA・サービスBに一度はログインしたことがある前提で進めます。前述のOpenID Connectの仕組みを一通りなぞったあと、ということです。

先程のOpenID Connectの仕組みと照らし合わせながら確認してみましょう。

Userは次に同じサービスにログインする際、OpenID Providerにログイン情報が残っていれば、サービスAとサービスBの両方でログイン処理をする必要がありません。

事前に属性情報の提供を許可しているため、サービスA・サービスBにログイン要求をした際には、それぞれがRelying PartyとしてOpenID Proverに問い合わせます。

Relying PartyとOpenID Providerの間でIDトークン・アクセストークンをやり取りするため、User側は関与する必要がなくなります。

以上がシングルサインオンの仕組みです。

　

OpenID Connectの仕組みを実際に触って理解しよう

OpenID Connectは、OAuth2.0を拡張し、システム間での認証を可能とする認証プロトコルです。両者の仕組みは似ていますが、それぞれ認証・認可と主要な目的が分かれているため注意が必要です。OpenID Connectが認証、OAuth2.0が認可と覚えておきましょう。

近年、クラウドサービスの業務利用が増え、各種サービス間の連携が重要になってきています。より深く、実践的な内容について学びたい方には、以下の動画講座がおすすめです。

認証や認可は文字だけでは分かりづらい部分が多いといえますが、動画講座であればよりわかりやすく理解が進むでしょう。動画講座はスマホでも視聴できるため、ぜひ一度受講してみてはいかがでしょうか。

手を動かして理解する！OAuth2 / OpenID Connect の基礎と活用

レビューの一部をご紹介

評価：★★★★★
コメント：認証周りの理解があまりできいない状態でしたが、このコースを通じて自信を持てるようになりました。図などを用いて解説されており、とてもわかりやすかったです。

評価：★★★★★
コメント：とても満足しています。
あまりOAuth2やOIDCの違いや仕組みを理解せず、雰囲気でこれまで利用していました。
このコースを通じて、仕組みを理解することができ、自信を持って今後は利用することができそうです。

OpenID ConnectとOAuthの仕組みと違いを正しく理解し、安全なアプリを開発しましょう！