APIのセキュリティプロトコル、OpenIDとOAuthの違い
英語によるオリジナルはこちらでご覧いただけます。
OpenIDとOAuthはどちらもデジタルIDに関連する規格という点では、よく似た印象を受けます。しかし、両者には違いがあります。OpenIDは、複数のサイトやサービスにシングルサインオン（SSO）で接続できるようにする規格です。一方OAuthは、アプリケーションにアクセストークンを付与し、限定的なアクセスを許可するための規格です。
どちらも、シンプル、シームレス、セキュアな認証を実現するときに使われる技術ですが、似た印象とは裏腹に、中身はまったくと言っていいほど異なります。OpenIDではユーザーのログインを認めることに主眼が置かれているのに対し、OAuthではアプリケーションのアクセスを認めることに主眼が置かれています。
この記事では、OpenIDとOAuthの主な違いや、ニーズに合った手法の選び方について説明していきます。
メモ：OAuthやOpenID Connectのワークフローを今すぐ試してみたい方は、Kong Konnectの無料トライアルにご登録のうえ、OpenID Connectプラグインの認証コードフローに関する解説を参考にしてください。
OpenIDとは
OpenIDは、デジタルIDの非集権化を可能にするオープン標準で、共通のIDプロバイダを通じて複数のウェブサイトにログインする機能を提供します。例えば、SSOを選択したユーザーは、GoogleやFacebookのアカウントをさまざまなウェブサイトへのログインに利用できます。サイトごとにユーザー名とパスワードを作り直す必要はありません。
OpenIDのメリットに利便性と可搬性があります。ユーザーが認証情報をいくつも覚えておく必要がなく、1つのIDプロバイダに認証を任せることができます。つまり、同じIDを複数のウェブサイトへのアクセスで簡単に再利用できます。
一方で、弱点も考えておくことが重要です。OpenIDには、単一障害点の発生に伴うリスクがあります。OpenIDプロバイダが侵害を受けた場合、そのIDを利用しているすべてのウェブサイトに影響が及びかねません。OpenIDでニーズを満たせるかどうかを考えるときには、こうしたトレードオフを理解する必要があります。また、サードパーティのプロバイダに認証を委ねることは、ログインプロセスを効率化できるというメリットがある一方で、プライバシやセキュリティの懸念にもつながります。
OAuthとは
OAuthは、認可のためのプロトコルです。ユーザーがどこかのサイトに保存しているデータに、別のサイトやアプリケーションからのアクセスを可能にしたいときに、認証情報を明らかにすることなく、限定的なアクセス許可を与えることができます。例えば、ユーザーがソーシャルメディアサイトに投稿した写真に、サードパーティのアプリケーションからアクセスできるよう、OAuthで認可を付与できます。この方法なら、ソーシャルメディアのパスワードをアプリケーション側に知られずに済みます。
最も重要なメリットは、パスワード自体を直接共有する方法に比べて、ユーザーがより安全に認可を委譲できることです。限定的なアクセス権を付与し、いつでも取り消すことができます。
一方でOAuthは、開発者にとっては複雑な部分があり、またユーザーにとっては多少のリスクが伴います。認可の手順については、ユーザーに教育が必要です。ユーザーは、OAuthでアプリケーションに付与するアクセス許可を慎重に行う必要があり、機密データへのアクセス許可をやみくもに付与してはなりません。OAuthを利用することで、サイト間でのセキュアなデータ共有が可能になりますが、ユーザーとしては、トレードオフが目的のユースケースに見合っているかどうかを評価する必要があります。
OAuth 2.0とは
OAuth 2.0は、認可のためのオープン標準であるOAuthの最新バージョンです。保護されているユーザーデータにアプリケーションやAPIがアクセスするための権限をセキュアに委譲できます。OAuth 2.0は、新しい暗号化手法への対応や認可コードの付与など、いくつかの点でAPIセキュリティが強化されています。
あわせてOAuth 2.0は、開発者の手間を軽減し、ウェブ、モバイル、デスクトップアプリ向け認可フローを最適化します。新たに加わった許可タイプは、クライアントの開発のしやすさや、ユーザーのセキュリティ強化に主眼を置いています。このようにOAuth 2.0は、柔軟にしてセキュアな認可フレームワークとして業界標準の地位を確立し、サードパーティのアプリケーションやAPIが別のサイトのユーザーデータに安全にアクセスできる環境を実現しています。
OAuthとOpenIDの比較のポイント
OpenIDはユーザー認証に主眼があるのに対し、OAuthは認可の委譲に主眼があります。OAuthは柔軟性に優れ、業界で広く採用されています。一方、OpenIDはよりシンプルですが、カスタマイズ性では劣ります。両者の主な違いを理解しておくと、それぞれに適合したユースケースを判断しやすくなります。
目的
OpenIDはユーザーをクライアントアプリケーションにログインさせるための認証プロトコルであり、目的はユーザー認証です。
OAuthは、クライアントアプリケーションがユーザーの代わりにサーバーリソースにアクセスできるよう、権限を委譲するための認可プロトコルです。その目的は、認可の委譲にあります。
フロー
OpenIDでは、認証リクエストを使用します。ユーザーは認証のためにOpenIDプロバイダにリダイレクトされ、そちらでサインインした後で、再び元の場所にリダイレクトされます。
OAuthでは、クライアント、リソースサーバー、認可サーバー間でトークンの交換が行われます。リダイレクトは行われません。
対象範囲
OpenIDでは、エンドユーザーのID検証が行われますが、その他のユーザー情報は提供されません。そのスコープは、認証に限定されています。
OAuthは、保護されているリソースへの特定のアクセス権の検証と付与を行います。対象範囲はカスタマイズ可能で、委譲された範囲にのみアクセスできます。
使用用途
OpenIDは、ウェブのシングルサインオンでよく使われます。GoogleやFacebookなどのアカウントを使用するソーシャルログインは、OpenIDを基盤としています。
OAuthは、ソーシャルメディアやクラウドストレージなどのサイトにユーザーが保持しているデータへのアクセス権を、そのサイトとは異なるサードパーティのアプリケーションに付与する用途で使われます。
標準
OpenIDはオープン標準の規格です。OpenIDに準拠したIDサービスを、複数のプロバイダが提供できます。
OAuthは、1.0、2.0といった複数のバージョンがあるフレームワークで、バージョン間の互換性はありません。OAuthには複数の拡張許可タイプがあります。
複雑さ
OpenIDでは、トークンは使用されません。開発者はプロトコルのフローをよりシンプルに実装できます。
OAuthでは、署名付きトークンが使用されます。トークンの交換に伴う追加の手順が必要となり、実装がより複雑です。
カスタマイズ
OpenIDは、シンプルなシングルサインオンのユースケース向けに設計されているため、カスタマイズの余地がほとんどありません。
OAuthでは、トークンのスコープ、エンドポイント、有効期限、リフレッシュなどを幅広くカスタマイズできます。
採用
FacebookやGoogleなどのアカウントを利用するソーシャルログインが普及するにつれて、OpenIDは勢いを失いました。
OAuthは業界全体で広く採用され、モバイルアプリやウェブAPI向けの用途、あるいはサードパーティがユーザーデータにアクセスできるようにする用途で使われています。
両方の特長を兼ね備えたOpenID Connect（OIDC）
OpenID Connectは、OAuth 2.0を拡張した認証プロトコルで、サインオンに利用できます。クライアントは認可サーバーを通じてユーザーのIDの検証を効率的に進められます。OpenID ConnectはOpenIDとOAuthの両方の要素を兼ね備えています。
OpenID Connectは、OAuth 2.0と同様のフローで認証のリクエストとレスポンスを処理し、OpenIDと同様のシームレスなシングルサインオンを実現します。また、APIへのアクセスやユーザー情報の取得でクライアントが利用できるOAuth 2.0のトークンを取り入れています。
このように、OpenID ConnectはIDの検証と認可の委譲という両方の機能を持ち、クライアントがユーザーデータにセキュアにアクセスできる環境を実現します。OpenID Connectは、OAuth 2.0の拡張版として、ユーザープロファイルクレームを使用するIDレイヤーを取り入れています。それにより、OAuthの認可フレームワークを土台として、シングルサインオン機能が実現します。
OpenID、OAuth、OpenID Connect（OIDC）の選択のポイント
アプリケーションの認証と認可を設計するときに使われているプロトコルには、OpenID、OAuth、OpenID Connectの3種類があります。APIファーストの企業への移行を達成するためには、それぞれのプロトコルの特長を理解することが重要です。
OpenIDは、シングルサインオンを通じてユーザーのID検証が求められる状況に最適です。ログインを統合する用途や、複数のサイトに簡単にサインインできるようにする用途では、OpenIDを選ぶのがシンプルです。
一方OAuthは、ユーザー関連の保護リソースにアプリケーションがアクセスできるようにする用途に適しています。ユーザーの認証情報を露出することなく、トークンを利用して認可を付与できます。OAuthは、APIアクセスの認可や、サードパーティのアプリケーションの有効化に利用されています。
OpenID Connectは、OpenIDのID検証とOAuthのアクセス委譲の機能を兼ね備えています。OAuth 2.0をベースとし、ユーザーのシングルサインオンの機能と、クライアントがユーザーデータにアクセスできるように認可を付与する機能の両方を提供します。一方で、OpenID Connectには、OAuthと同じような複雑さがあります。
認証APIの統合やユーザー体験に関する具体的なユースケースを評価することによって、シンプルさ、セキュリティ、機能のバランスがとれた最適なプロトコルを選択できます。そのためには、OpenID、OAuth、OpenID Connectの基本的な存在意義を理解することが不可欠です。
まとめ
OpenIDとOAuthは、オンラインのIDの処理やAPIアクセス制御に広く普及しているプロトコルです。OpenIDはシングルサインオンでのユーザー認証に使用されるのに対し、OAuthではユーザーデータにアクセスするアプリケーションに認可を委譲することができます。OpenIDはIDを検証し、OAuthは限定的なアクセス権を付与するという点を理解することが、きわめて重要です。また開発者は、適切なプロトコルを選択するために、プロトコルのフロー、標準化、複雑性、カスタマイズ性という面での違いも考慮する必要があります。全体として見れば、OpenIDとOAuthは、それぞれ異なる役割を果たすことで、セキュアなデジタルIDとアクセス認可を実現しています。API向けの用途や、サードパーティアプリケーションの統合に関しては、OAuthの方が広く採用されています。