Webサービスやスマートフォンアプリを利用していると、「Googleでログイン」「Appleでサインイン」など、別のサービスのアカウントを利用する機能を目にすることがあります。こうした外部サービスとの連携に関連して広く利用されている仕組みが「OAuth（オーオース）」です。
一般には「OAuth認証」と呼ばれることがありますが、OAuthの本来の目的は「認証」ではなく「認可」です。
この記事では、OAuthとは何か、どのような仕組みで動作するのか、OAuth 2.0やOpenID Connectとの違いなどをわかりやすく解説します。
OAuthとは
OAuthとは、ユーザーが利用しているサービスのパスワードを第三者のアプリケーションに渡すことなく、そのアプリケーションに特定の操作や情報へのアクセス権限を与えるための仕組みです。
たとえば、あるアプリがユーザーの別サービス上のデータを利用したい場合を考えてみましょう。
ユーザー名とパスワードをそのアプリに直接入力して渡してしまう方法では、アプリ側に重要な認証情報を預けることになります。
OAuthでは、パスワードそのものを第三者のアプリに渡すのではなく、許可された範囲で利用できる「アクセストークン」を用いてアクセスさせます。
そのため、OAuthは「パスワードを第三者に渡さず、必要な権限だけを委譲するための仕組み」と考えると理解しやすいでしょう。
「OAuth認証」という呼び方は厳密には正しくない
OAuthについて特に注意したいのが、「OAuth認証」という表現です。
日常的にはOAuth認証と呼ばれることがありますが、OAuthは本来、認証（Authentication）の規格ではなく認可（Authorization）のための仕組みです。
認証とは、「そのユーザーが誰なのか」を確認することです。
一方の認可とは、「そのユーザーやアプリケーションに何を許可するのか」を決めることです。
たとえば、ログイン時にIDとパスワードを確認して本人であることを確かめる処理は認証です。それに対して、「写真を読み取ってよい」「カレンダーを参照してよい」といった権限を与える処理は認可に該当します。
OAuthが主に担当するのは後者です。
OAuthが必要とされる理由
OAuthのような仕組みがなければ、異なるサービス間でデータを連携するとき、ユーザーのIDやパスワードを連携先のサービスに渡す方法が考えられます。
しかし、この方法には大きな問題があります。
パスワードを第三者に知られる可能性があるだけでなく、一度パスワードを渡してしまうと、そのサービスに必要以上の操作を許してしまう危険性があります。
OAuthでは、アクセストークンを使用してアクセスを許可します。また、アクセスできる範囲を限定する「スコープ」を設定できます。
これにより、パスワードを共有することなく、必要な権限だけを第三者のアプリケーションに与えることができます。
OAuthの基本的な登場人物
OAuthの仕組みを理解するうえでは、いくつかの役割を知っておく必要があります。
リソースオーナー
保護されたデータへのアクセスを許可する主体です。
一般的なWebサービスでは、サービスを利用しているユーザーがリソースオーナーになります。
クライアント
ユーザーに代わって、保護されたリソースへのアクセスを要求するアプリケーションです。
たとえば、別サービスのデータを利用するWebアプリやスマートフォンアプリなどが該当します。
認可サーバー
ユーザーから許可を得たうえで、クライアントにアクセストークンを発行する役割を持つサーバーです。
リソースサーバー
ユーザーの保護されたデータやAPIなどを提供するサーバーです。
クライアントからアクセストークンを受け取り、そのトークンが適切であればリソースへのアクセスを許可します。
OAuthの基本的な仕組み
OAuthを利用した連携では、概ね次のような流れで処理が行われます。
- ユーザーが外部サービスとの連携を開始する
- クライアントが認可サーバーへユーザーを誘導する
- ユーザーが必要な権限を確認する
- ユーザーがアクセスを許可する
- クライアントが認可サーバーから必要な情報を受け取る
- クライアントがアクセストークンを取得する
- アクセストークンを使ってリソースサーバーへアクセスする
実際の通信方法は利用するフローによって異なりますが、ユーザーのパスワードそのものをクライアントに渡さずにアクセス権を委譲することが重要なポイントです。
アクセストークンとは
アクセストークンとは、クライアントがリソースサーバーへアクセスするときに使用する情報です。
クライアントはユーザーのパスワードを使用する代わりにアクセストークンを提示し、許可されたリソースへアクセスします。
アクセストークンは重要な情報であり、漏えいすると第三者に悪用される可能性があります。そのため、安全な通信や適切な保存・管理が必要です。
また、アクセストークンには有効期限が設定される場合があります。
リフレッシュトークンとは
OAuthでは、アクセストークンとは別に「リフレッシュトークン」が利用されることがあります。
アクセストークンの有効期限が切れた場合、条件を満たしていれば、リフレッシュトークンを使って新しいアクセストークンを取得できます。
これによって、ユーザーに毎回同じ認可操作を求めることなく、一定期間サービス連携を継続できます。
ただし、リフレッシュトークンも重要な情報であるため、厳重な管理が必要です。
スコープとは
OAuthにおける「スコープ（Scope）」とは、クライアントに許可するアクセス権限の範囲を表すものです。
たとえば、サービスによっては次のように権限を分けることができます。
- プロフィール情報を参照する
- メールアドレスを参照する
- カレンダーを参照する
- ファイルを読み取る
- データを作成・更新する
スコープを利用することで、アプリケーションに必要な権限だけを与えることができます。
セキュリティの観点からは、必要以上に広いスコープを要求せず、サービスの機能に必要な最小限の権限に限定することが重要です。
OAuth 2.0とは
現在広く知られているOAuthの仕様が「OAuth 2.0」です。
OAuth 2.0は、Webアプリケーション、スマートフォンアプリ、API連携など、さまざまな環境で認可を実現するために利用されています。
なお、OAuth 2.0はOAuth 1.0を単純に拡張した上位互換規格というわけではなく、設計や仕組みに大きな違いがあります。
OAuthを実装する場合は、使用するサービスやライブラリの仕様を確認し、現在推奨されているセキュリティ対策を採用することが重要です。
Authorization Codeとは
OAuth 2.0で代表的な仕組みの一つが「Authorization Code（認可コード）」を利用する方式です。
ユーザーが認可を行うと、クライアントはまず認可コードを受け取ります。その後、クライアントがその認可コードを認可サーバーへ送り、アクセストークンと交換します。
アクセストークンをブラウザ経由で直接受け取るのではなく、認可コードを介して取得する仕組みになっています。
OAuth 2.0の実装では、このAuthorization Codeを利用したフローが重要な方式の一つです。
PKCEとは
PKCEは「Proof Key for Code Exchange」の略で、Authorization Codeを利用する際の安全性を高める仕組みです。
クライアントは認可リクエストを開始するときに、ランダムな値を基に生成した情報を認可サーバーへ送信します。そして、認可コードをアクセストークンへ交換するときに対応する値を提示します。
これにより、認可コードが第三者に奪われた場合でも、そのコードだけではアクセストークンを取得しにくくなります。
現在OAuthを実装する際には、利用する環境や仕様に応じてPKCEを適切に使用することが重要です。
OAuthとOpenID Connectの違い
OAuthと一緒に登場することが多い技術に「OpenID Connect（OIDC）」があります。
両者は目的が異なります。
OAuth 2.0の主な目的は「認可」です。
一方、OpenID ConnectはOAuth 2.0を基盤として、ユーザーの「認証」を行うための仕組みを追加したものです。
OpenID Connectでは、ユーザーを識別するための情報を含む「IDトークン」が利用されます。
そのため、「外部サービスのアカウントを使ってユーザーが誰なのかを確認し、ログインさせる」という用途では、OAuth 2.0だけではなくOpenID Connectが利用されます。
アクセストークンとIDトークンの違い
OAuthやOpenID Connectを理解するときには、「アクセストークン」と「IDトークン」を混同しないことが重要です。
アクセストークンは、APIなどの保護されたリソースへアクセスするために使用されます。
一方、IDトークンはOpenID Connectにおいて、認証されたユーザーに関する情報をクライアントへ伝えるために使用されます。
つまり、大まかには次のように役割を分けられます。
アクセストークンは「何にアクセスできるか」に関係し、IDトークンは「誰が認証されたか」に関係します。
OAuthを利用するメリット
OAuthには、サービスを提供する側とユーザー側の双方にメリットがあります。
代表的なメリットは、ユーザーのパスワードを第三者のアプリケーションに渡さずにサービスを連携できることです。
また、スコープによってアクセス権限を限定できます。
さらに、サービスによってはユーザー側で連携を解除できるため、パスワードそのものを変更することなく特定のアプリケーションからのアクセスを停止できます。
APIを提供するサービスにとっても、アクセス権限を管理しながら外部アプリケーションとの連携機能を提供できる点がメリットです。
OAuthを利用するときの注意点
OAuthを利用すれば自動的に安全になるわけではありません。
実装方法に問題があれば、アクセストークンの漏えい、認可コードの不正取得、不適切なリダイレクトなどにつながる可能性があります。
そのため、OAuthを実装する場合は、HTTPSの使用、リダイレクトURIの適切な検証、stateなどを利用したリクエストの保護、PKCEの適切な利用、トークンの安全な保存など、仕様や最新のセキュリティ上の推奨事項に従う必要があります。
また、ユーザー側も、連携画面に表示される権限を確認し、必要以上のアクセス権限を要求するサービスには注意することが大切です。
OAuthはどのような場面で使われる？
OAuthはさまざまなサービス連携で利用されています。
代表的なのは、外部サービスのAPIへアクセスするアプリケーションです。
たとえば、ユーザーの許可を得たうえで、カレンダー情報を取得したり、クラウド上のファイルへアクセスしたりするサービスが考えられます。
また、OAuth 2.0を基盤とするOpenID Connectと組み合わせることで、外部のIDプロバイダーを利用したログイン機能にも活用できます。
OAuthは、Webサービス同士を安全に連携するための重要な基盤技術の一つとなっています。
まとめ
OAuthは、ユーザーのパスワードを第三者のアプリケーションへ渡すことなく、特定のリソースへのアクセス権限を委譲するための仕組みです。
一般には「OAuth認証」と呼ばれることもありますが、OAuthそのものが担当するのは基本的に「認証」ではなく「認可」です。
OAuth 2.0ではアクセストークンやスコープなどを利用して、アプリケーションに必要なアクセス権限を与えます。また、ユーザーのログイン・認証を目的とする場合には、OAuth 2.0を基盤としたOpenID Connectが広く利用されています。
「OAuth＝ログインの仕組み」と単純に考えるのではなく、「OAuthはアクセス権限を委譲する仕組み」「OpenID ConnectはOAuth 2.0を基盤として認証機能を提供する仕組み」と区別すると理解しやすいでしょう。
コメント