OAuthとは？ 認証はどのように機能する？

OAuthとは？

OAuthは、アプリに組み込むことで、利用者に安全な限定アクセスを提供できるオープンスタンダードな認可プロトコルです。例えば、このプロトコルを使えば、Facebookに、ログイン情報を開示することなくESPN.comがソーシャルメディアの投稿や更新情報にアクセスできるよう指示することができます。この仕組みによりリスクが大幅に低減され、ESPN.comでデータ漏えいがあった場合でも、Facebook上の情報は守られます。

OAuthは他のプラットフォームとパスワードを共有するのではなく、認可トークンを送信します。このトークンによって本人確認が行われるのです。利用者とサービス提供者の間で活用すべき重要な仕組みであり、簡単に言えば、パスワードを渡すことなくプラットフォームやサービス同士が連携するための認証プロトコルです。

‍

OAuthの例

一般的な例として、多くのAndroidスマートフォンが挙げられます。Androidスマートフォンを購入すると、ほとんどの機能を利用するために、メールアカウントにログインする必要があります。

スマートフォンにメールでログインすると、その情報が他のアプリやウェブサイトへのアクセスに利用されます。OAuthの仕組みなら、メールのログイン情報を即時にプラットフォームと共有でき、パスワードを入力せずとも、サイト側で認証が完了して限定アクセスが提供されます。

このプロトコルの考え方を示す利用例は他にも多数あり、パスワードを何度も入力せずに複数のプラットフォーム間で認証情報を共有できる点が特徴です。

原理的な例として、他のサイトにリダイレクトされ「他サイトの認証情報で本サイトにログインしますか？」というメッセージが表示されるケースがある。ここで、認証を要求するサイトを受信者、現在ログイン中のプラットフォームを送信者と呼び、受信サイトへのログイン時に送信者と同一の利用者かを確認します。

Facebookは、このプロトコルを利用する代表的なプラットフォームです。Facebook上のアプリを利用する際、プロフィール情報や写真へのアクセスが求められ、この場合、Facebookが送信者としてログイン情報や写真を提供します。アプリが受信者となり、利用者はそのサービスを使うため、許可をクリックすることで受信者に写真へのアクセス権が与えられ、OAuthが全体の流れを円滑にします。

テレビ、セキュリティシステム、トースターなどのスマートホームデバイスは、ブラウザやモバイル端末から一括管理するためにログインが必要です。これらはOAuthの機密認証方式を採用して、ログイン情報を安全に保持。これにより、異なるサイトで毎回ログイン情報を入力する必要がありません。

‍

OAuthの歴史

OAuthは一人の手によるものではなく、GoogleやTwitterなど多数の大手テック企業が協力して国際的に認められる認可標準として策定されました。2010年にRFC 5849として公開され、すぐにAPIコミュニティで広く知られるようになりました。その後、時の経過と共にコミュニティからの要望によってアップデートが求められ、複数のバージョンが誕生しました。

RFC 6749、すなわちOAuth 2.0は2012年に登場した第2版で、当初は批判を受けましたが、後に広く普及し、Netflix、Facebook、PayPal、Amazonなどの企業で利用されています。

‍

OAuthの要素

• OAuthトークン

従来の銀行トークンが顧客の行列参加や現金引き出しに使われたように、デジタルトークンはシステムリソースの利用許可にも用いられます。OAuthトークンには次の2種類があります：

1. ‍タイプ1：アクセス・トークン

一時的なリソースアクセスの許可と考えてほしい。

これらは有効期限付きで、API利用者がAPI呼び出しに使用するため、数分や数時間のみ有効です。プライベート、パブリックどちらのクライアントでも利用可能で、インターネットのスケーラビリティ問題の解決にも寄与します。短期間のため、利用者がアクセストークンを取り消すのは容易ではありません。

2. ‍タイプ2：リフレッシュ・トークン

一度だけでなく、一定期間内に複数回リソースへアクセスできるパスのようなものです。

リフレッシュ・トークンはアクセス・トークンに比べて有効期限が長く、場合によっては数年間有効です。主な目的は新たなアクセストークンの取得であり、十分な認証機能を持つプライベートクライアントでのみ機能します。

また、アクセス・トークンと異なり取り消しが容易ですが、アプリのアクセスを取り消す際にリフレッシュ・トークンが無効になってデータ漏えいを引き起こす恐れがあり、強制的に新トークンを取得しようとするため、APIリソースに悪影響を及ぼす可能性があります。

これらのトークンの形式には決まりはなく、選択した形式で利用できますが、セキュリティ上の理由から、API開発者はデジタル署名が可能なJSON Web Token (JWT) を好む傾向にあります。

各エンドポイント（一般的には「Authorize」と「Token」）を介して双方のトークンを取得可能です。各エンドポイントは固有の用途があり、例えば、利用者の権限や本人確認を行うのは「Authorize」です。

‍

• OAuthスコープ

この情報の配列は、アクセス権要求時にアプリや利用者と共有されます。アプリは事前に認可を受ける必要があり、スコープは複数あり、クライアント側がリクエストする権限を示します。

アプリ開発者によって設計され、コーディング・デザイン開始時から存在し、認可ポリシーの分離に有用です。

スコープはOAuthの主要な要素で、権限が明確に前面に出されることを示しており、利用しているAPIのOAuthスコープは、APIドキュメントで確認できます。

‍

• OAuthの関係者

1. リソース所有者はエンドユーザー、企業、または団体であり、リソースサーバにアクセスでき、そこに保存された全体または一部のデータを所有します。たとえば、ソーシャルメディアのアカウントを持つ全ての利用者は、自身のプロフィールの所有者です。パスワードやユーザー名、その他の情報はリソース所有者の所有物です。
2. リソースサーバは対象のウェブサイトやアプリが取得したいデータを保持するAPIです。たとえば、FB Messengerアプリがログイン完了のために利用するログイン情報を保持するFB APIが該当します。
3. クライアントは、ログイン情報などにアクセスし、システム利用を可能にするアプリです。プライベートまたはパブリックのいずれかであり、Facebookアカウントにアクセスする場合、そのアプリがクライアントとなります。

‍

• OAuthのフロー

1. ‍インプリシット・フロー

この方式はブラウザ上のみで通信が行われ、バックエンドサーバが認可の権限を管理しません。SPA（シングルページアプリ）が該当し、ブラウザベースのパブリッククライアントでのみ適用され、リフレッシュ・トークンは使用せずアクセス・トークンのみが利用されます。完全にブラウザ上で動作するため、サイバー攻撃に弱い面があります。

2. ‍オーソリゼーションコード・フロー

別名「3レッグド」とも呼ばれ、OAuthのゴールドスタンダードとされるこのフローは、フロントチャネルとバックチャネルの両方を利用します。クライアントアプリはフロントチャネルで認可コードを取得し、バックチャネルでその交換を行います。

3. ‍クライアントクレデンシャル・フロー

ここで言うクライアントは、サーバと通信するアプリやブラウザを意味します。認証情報の交換に関するフローであるため、セキュリティが最優先されます。

このフローはサーバ間の通信に最適で、クライアント情報を用いバックチャネルのみでアクセストークンに到達します。左右鍵によってクライアント情報が保護されるため、情報の安全性が維持されます。

4. ‍リソース所有者パスワード・フロー

直接認証プロセスに似たレガシーなフローですが、セキュリティ面に欠けるため推奨されません。リフレッシュ・トークンのサポートもなく、パブリッククライアントとリソース所有者が同一であると仮定しています。

5. ‍アサーション・フロー

最新のフローで、クライアントクレデンシャル・フローに類似し、フェデレーションの概念をサポートするために作られました。認可サーバが第三者の認可権限を受け入れ管理することを可能にし、SAML等の技術を多用する組織で利用されます。

6. ‍デバイス・フロー

デバイス・フローはウェブベースではなく、デバイス固有の方式です。クライアントアプリがバックチャネルを使って認証承認状況を確認し、アクセス・トークンとリフレッシュ・トークンの両方を取り扱います。

‍

OAuthの仕組み

実際、OAuthは認証ではなく認可に重点を置いて設計されています。認可とは、特定の行動を行うための許可を求めることであり、認証とは、プロフィール内の情報にアクセスする権限がある本人であることを確認する手段です。OAuthは利用者に認証を求めるのではなく、他のアプリやリソースへのアクセスを許可します。

このプロトコルの動作原理を理解する一例として、バレットキーの例が挙げられます。バレットキーは、運転を許す一方でトランクを開けさせないよう設計されています。同様に、OAuthトークンはスマートデバイスへのバレットキーの役割を果たし、利用者はプラットフォーム間で共有する情報を管理できます。各受信者にバレットキーを渡すことは可能ですが、受信者はそのキーや機密情報の全体にアクセスすることはありません。

OAuth取引には、利用者、送信者、受信者の3者が関与します。これを「OAuthラブトライアングル」と呼ぶこともでき、以下の簡単な手順で、複数プラットフォームでの認証保護の仕組みが説明される。

• ステップ1：利用者が意図を示す
• ステップ2：受信者が許可を取得する。許可とともに送られる秘密情報により、偽造防止と要求元の確認が行われる
• ステップ3：利用者がサービス提供者または送信者にリダイレクトされる
• ステップ4：利用者が許可を与える
• ステップ5：受信者がアクセストークンを取得する
• ステップ6：受信者が保護されたリソースにアクセスする

SAMLとOAuthの比較

SAMLとOAuthには類似点に言及されることもありますが、基本的な考え方は大きく異なります。SAML（Security Assertion Markup Language）は、シングルサインオン機能を支える別の認証標準で、企業が社内リソースの管理者を監視するために利用されます。

SAMLはXMLを用いてメッセージを送信するのに対し、OAuthはJSON技術を使います。また、OAuthはシンプルなモバイル体験を念頭に設計され、SAMLはより高いセキュリティを提供します。さらに、OAuthはAPIに大きく依存しているため、多くのモバイルアプリ、現代のウェブサイト、ゲーム機、IoT機器がこのプロトコルを採用しています。一般的に、OAuthは利用者に快適な体験を提供します。一方、SAMLは利用者のブラウザにクッキーセッションを設定し、短期間のアクセスには適していますが、頻繁なログインには不向きです。

‍

記事の比較 - OAuthとSAML/OpenIDの違い

OpenIDとOAuthの比較

簡単に言えば、OpenIDは認証目的で利用され、OAuthは認可のためのプロトコルです。

OpenIDはフェデレーテッド認証に対応しており、既存のアカウントで第三者アプリの認証をサポートします。一方、OAuthは、第三者アプリでログイン情報を入力する手間を省くために設計されています。

両プロトコルは類似のタスクを実現できますが、互換的に使うべきではありません。OpenIDは本人確認を提供し、OAuthはより汎用的な仕組みです。OAuth利用時、サーバは第三者にアクセストークンを発行し、そのトークンで保護されたリソースにアクセスしますが、トークン所有者の身元が検証されることはありません。

‍

‍

OAuth 1.0とOAuth 2.0の比較

OAuth 2.0は、OAuth 1.0の仕組みを大幅に改善するために設計され、両者は互換性がありません。新たなアプリやサイトを構築する際は、OAuth 2.0を採用することが望ましく、多くの現代サイトはOAuth 1.0が廃止されたため、既にOAuth 2.0へ移行しています。

最新バージョンであるOAuth 2.0は、アプリやサイトへの実装がより簡単かつ迅速に行えます。OAuth 1.0は暗号要件に依存し、3種類以上のフローやスケーリングに対応していませんでした。

OAuth 2.0は、様々なアプリや要件に応じた6種類のフローを備え、HTTPS上で署名されたシークレットを利用できる認証プロトコルです。トークンはエンドポイント間で既に暗号化されているため、再度暗号化する必要はありません。

OAuthは安全か？

OAuthがどこまで役立つかを評価することは重要です。TLS暗号化は十分な安全性を保証しますが、その実装の品質が肝心です。OAuthを利用する際、TLS暗号化無しでのコーディングが行われていないか確認する必要があります。認証時に自動的にTLS暗号化を実施するコードを組むことも可能です。

もしTLS暗号化が至る所に適用されず、セキュリティの穴がある場合、悪意あるサイトがログイン情報をフィッシングして利用者に不利益を与える可能性があります。2017年には、この方法で100万以上のGoogleアカウントがフィッシング被害に遭った事例もあります。したがって、OAuthは完全に安全というわけではなく、実装時の十分な注意が求められます。

‍

OAuthがAPIを守る仕組み

API Connectを使えば、APIを守ることが可能です。OAuthは、利用者の認証情報や個人情報を記録することなく、第三者サイトやアプリの利用を可能にする特別な認可プロトコルです。

OAuth利用シナリオ

API Connectと併用する場合、APIを守るために以下のような方法が利用できます：

• OAuthプロバイダーAPIの作成。プロバイダーAPIには、OAuthフローの両エンドポイント用のトークンが含まれる。
• OAuthセキュリティ定義を利用したAPIの保護。アプリやサイトにこのセキュリティ定義を追加することで、OAuth認可基準に基づいたAPI操作の制御が可能となる。
• OAuthメタデータURLおよび認証URLの設定。これらのURLを用いて、リモートサーバから利用者固有のコンテンツを取得し、アクセストークンまたはセキュリティトークンを含むペイロードの一部として付加する。

OAuthのレスポンス

OAuth 2.0のプロセス中、API Connectは様々なリクエストに対してレスポンスを返します。

OAuthのトラブルシューティング

もしこのプロトコルに関して問題が生じた場合は、Developer PortalやYoutube、Github、DeveloperWorksのフォーラムで情報を集め、自力で対処してください。