OAuth とは？

OAuth (Open Authorization) は、ユーザーが自分のログイン情報を第三者と共有することなく、外部アプリケーションに自分のリソースへのアクセスを許可できるオープン標準の認可プロトコルです。パスワードを直接渡す代わりに、OAuthは一時的なアクセストークンを使用して、ユーザーに代わって外部アプリにアクセスを許可します。

例えば、メールマーケティングツールであるMailchimpのようなサードパーティアプリを使って、Googleコンタクトをインポートし、メールリストを作成したいとします。通常であれば、各連絡先を手動でダウンロードしてからMailchimpにアップロードする必要がありますが、OAuthを使えば、GoogleアカウントをMailchimpに安全に接続し、パスワードを公開することなく、連絡先への限定的なアクセス権を付与できます。

OAuthとOAuth 2.0の違い

OAuth (またはOAuth 1.0) では、各認可リクエストを暗号署名でサインする必要があります。つまり、サードパーティアプリは共有秘密鍵を使ってリクエストに署名し、認可サーバー側も同じ秘密鍵を用いて検証を行わなければなりません。暗号署名はリクエストが改ざんされていないことを保証しますが、データ自体を暗号化するものではないため、通信中に傍受や盗み見のリスクが残ります。

OAuth 2.0はOAuth 1.0の認可プロセスを簡素化し、暗号署名の代わりにHTTPS暗号化を使用することで、安全なエンドツーエンドのデータ通信を提供します。OAuth 2.0では、短期間有効なアクセストークンとリフレッシュトークンを使用することで、トークンの露出リスクを最小化し、セキュリティを強化します。また、ウェブアプリ、モバイルアプリ、サーバー間通信など、アプリケーションの種類に応じた複数の認可フローをサポートすることで、柔軟性も向上しています。

特徴	OAuth 1.0	OAuth 2.0
セキュリティ	各リクエストに対して共有秘密鍵による暗号署名を使用。改ざんは防止できるが、通信途中での傍受は防げない。	HTTPS/TLS暗号化を使用し、安全なエンドツーエンド通信を実現。
トークンシステム	単一のトークンタイプで、有効期限の規定はなし	短期間有効なアクセストークンとリフレッシュトークンを使用し、セキュリティを向上
リクエストの検証	アプリとサーバーの両方が一致する署名を生成してリクエストを検証	TLSでリクエストを暗号化し、検証を実施
認可フロー	すべての事例で単一フローを使用	複数のフローを用意し、ウェブアプリ、モバイルアプリ、サーバー間通信など、アプリケーションの種類に応じて対応
実装の複雑さ	暗号署名が必要なため実装が複雑	HTTPSに依存しているため実装は比較的簡単
利用状況	最新のアプリケーションではあまり使用されない	最新のアプリケーションにおける業界標準
セキュリティ上の妥協点	署名による追加のセキュリティ層があるが、実装はより複雑	TLSに依存しており実装は比較的簡単だが、署名による追加保護はない
推奨用途	署名検証が必要な既存のレガシーシステム	最新のアプリケーションやAPI

OAuthとOAuth 2.0はいずれも実用的な選択肢ですが、OAuth 2.0は実装が容易で、最新のアプリケーションでより広く利用されているため推奨されます。

OAuthの仕組み

以下に、Authorization Code Grantフローを使ったOAuth 2.0の動作手順をご説明します。

ユーザーが認可を開始: ユーザーは、サードパーティアプリ (クライアント) に、自分のサーバー上のリソースへのアクセスを許可したいと考えます。通常、これはクライアントアプリ上の「Googleでログイン」や「GitHubに接続」などのボタンをクリックすることで始まります。
クライアントが認可をリクエスト: クライアントはユーザーを認可サーバーの認可エンドポイントにリダイレクトします。リクエストにはclient_id、redirect_uri、response_type=code、scope、state (CSRF対策用) などのパラメータが含まれます。ユーザーは、まだログインしていない場合は認証を求められ、その後、要求されたアクセスの許可または拒否を選択します。
認可の付与: ユーザーがリクエストを承認すると、認可サーバーはユーザーのブラウザをクライアントのredirect_uriにリダイレクトします。URLには認可コードとstateパラメータが含まれます。クライアントは、このパラメータを確認して、リクエストが改ざんや傍受されていないことを検証します。
クライアントがアクセストークンをリクエスト: クライアントは、認可コードをトークンと交換するためにトークンエンドポイントにリクエストを送信します。リクエストには以下の情報を含める必要があります。authorization_code、client_id、client_secret (該当する場合)、redirect_uri (元のリクエストと一致する必要があります)、grant_type=authorization_code。
クライアントがアクセストークンとリフレッシュトークンを受け取る: リクエストが正当と確認されると、認可サーバーはアクセストークンを発行し、APIリクエストの認証に使用します。さらに、現在のアクセストークンが期限切れになった際に新しいトークンを取得するためのリフレッシュトークンも発行されます。クライアントはこれらのトークンを安全に保管し、APIリクエスト時にアクセストークンを利用します。
クライアントがリフレッシュトークンを使用: アクセストークンの有効期限が切れた場合、クライアントはリフレッシュトークンを使って新しいアクセストークンを取得できます。新しいアクセストークンを取得するには、クライアントはトークンエンドポイントに次の情報を含むリクエストを送信する必要があります。client_id、client_secret、refresh_token、grant_type=refresh_token。

OAuthの利点

OAuthを使用することで、認証情報の盗難リスクを低減し、ユーザー体験を向上させ、シングルサインオンの利用が可能になるという利点があります。

認証情報の盗難や不正使用リスクの低減

OAuthでは、ユーザーがサードパーティアプリに認証情報を直接共有する必要がなくなります。代わりに、認可サーバーがアクセスを管理するため、特にデータ漏洩時における認証情報の流出のリスクを大幅に低減できます。OAuth 2.0では、有効期限の短いアクセストークンを使用して、指定された期間だけリソースへの限定的なアクセスを許可します。これらのトークンはユーザーがいつでも取り消すことができ、アクセスが一時的でユーザーの管理下にあることが保証されます。

ユーザー体験の向上

OAuthを利用すると、ユーザーは既存のアカウントを使って複数のサービスやリソースにアクセスできるため、各サービスごとに新しいユーザー名やパスワードを作成する必要がなくなります。これにより、アクセスが迅速になり、複数のログイン情報を管理する手間も軽減されます。

シングルサインオンの実現

OAuthを利用すると、ユーザーは信頼できるサービスプロバイダで一度ログインするだけで、複数のアプリを再度認証情報を入力することなく利用でき、シングルサインオンを実現できます。ユーザーがプロバイダにログインしたままであれば、同じアカウントに接続された他のアプリもスムーズに利用可能です。例えば、Googleにログインしているユーザーは、Google認証を利用する他のアプリにもアクセスできます。

OAuthのデメリット

OAuthには利点がある一方で、セキュリティリスクも存在します。例えば、トークンが安全に保管、送信されない場合に漏洩する可能性や、ユーザーがフィッシング攻撃の被害を受ける可能性などがあります。

トークンが安全に保管されていない場合のリスク

アクセストークンやリフレッシュトークンは、ユーザーのデータやリソースへの直接アクセスを可能にするため、サイバー犯罪者にとって重要な標的となります。トークンが適切に保管されていない場合、攻撃者により漏洩、悪用され、アカウントの不正アクセスや情報の侵害につながる可能性があります。

トークンが安全に送信されていない場合のリスク

トークンがHTTPSではなくHTTPなどの安全でない接続経由で送信されると、中間者攻撃 (MITM) によって傍受される可能性があります。一度トークンが漏洩すると、不正にユーザーのリソースへアクセスされる恐れがあります。

フィッシング攻撃のリスク

OAuthでは、ユーザーを認可サーバーにリダイレクトして権限を付与する仕組みを利用しますが、このプロセスはフィッシング攻撃に悪用される可能性があります。フィッシング攻撃では、攻撃者が正規の認可サーバーを装った偽のログインページにユーザーを誘導します。ユーザーがその違いに気づかずに認証情報を入力すると、攻撃者にアカウントや機密データへのアクセス権が渡ってしまう恐れがあります。