OAuth（オーオース）認証とは？仕組み・課題・利用例・背景 - 権限認可システム

さまざまなWebサービスが乱立する現在、OAuthは必要不可欠なものとなりつつありますが、具体的にはどのようなシステムなのでしょうか。

この記事では、OAuth認証の仕組みや動作とともに解説していきます。

OAuth（オーオース）とは

OAuth（オーオース）とは、SNSやWebサービス間で「アクセス権限の認可」を行うためのプロトコルのことであり、現在では2012年に発行されたOAuth 2.0が標準化されています。

OAuthは何で使われているか

OAuthは、SNSやWebサービスを日常的に使用する私たちにとって、実は身近な存在です。

SNSアカウントやWebユーザーページなどにアクセスする際、そのサービスのユーザーだということを「ログイン」によって認可させなければなりませんが、これを行うインターフェイスをAPIといいます。

たとえば、InstagramとFacebookに同じ写真を投稿する場合、通常であれば双方のAPIを通じたログインが必要になるはずです。

しかし、実際はInstagramへのログインだけでどちらにも投稿が可能となっており、この共有機能に使われているのがOAuthプロトコルなのです。

APIについては以下の記事もご覧ください。

OAuthの利用例

先ほどのInstagramの例もOAuthを利用したサービスのひとつですが、その他には、はじめてのWebサービスを利用する際、「Facebookでログイン」という画面を見たことがある方も多いでしょう。

図はSkypeのログイン画面になりますが、これは、Facebookなどのユーザー認証を信頼したうえで、Webサービスがログイン情報を共有するというOAuthプロトコルの利用例になり、新規登録時などはアカウント情報入力の手間を大幅に減らしてくれます。

OAuthとOpenID

OAuthと似た機能を持つプロトコルとしては「OpenID」があります。
OpenIDもOAuth同様、オープンスタンダードとして公開されており、現在ではOpenID Connect 1.0が最新版となっています。

その違いは、OAuth 2.0がWebサービスを中心とした「HTTPプロトコル」であるのに対し、OpenID Connect 1.0ではOAuth 2.0をベースとしたHTTPプロトコルの他、スマートフォンを意識したXMPPなど、HTTP以外のプロトコルに拡張可能だという点にあります。

なぜOAuthが使われているのか

OAuthが登場した背景には、FacebookやTwitterなどWeb連携を行うサービスが増加し、それぞれのAPIを公開して共有するため、APIアクセスを認可する手段が必要とされたことがあります。

このような状況の中、OpenIDを使用したAPIアクセス委譲の方法を検討してい「Twitter」と「Ma.gnolia」が中心になり、OAuthのインターネットコミュニティが誕生、2007年にOAuth 1.0の最終草案がリリースされるに至ったのです。

OAuth 1.0が抱える3つの課題

リリース以来、順調に実装が進んだOAuth 1.0ですが、いくつかの課題も抱えていました。

認証と署名の複雑さ
認証と署名の複雑だったため、OAuthクライアント作成にはライブラリを必要としましたが、ライブラリ自体にバグが多く、ライブラリのない開発言語では作成自体できませんでした。

デスクトップ／モバイルアプリへの対応が不充分
OAuth 1.0はWebアプリへの対応が基本だったため、デスクトップ／モバイルアプリ上では上手く動作しませんでした。

プロバイダのサーバスケールが困難
OAuth 1.0は認証システムの複雑さから、サーバのスケールアップやスケールダウンによる機能強化が困難でした。

OAuth 2.0の標準化

OAuth 1.0では上述の課題に加えセキュリティ問題も判明しており、これらの課題を解決するために仕様策定され、2012年にRFCとして発行されたのがOAuth 2.0です。

インターネット上で公開され、誰でも閲覧できるRFCとして発行されたことからもわかるように、OAuth 2.0は開発途上の規格であるともいえます。しかし、膨大なユーザー数を誇るFacebookやTwitterが実装したことにより、事実上の標準化規格として扱われています。

OAuthが機能する仕組み

それでは、実際にOAuthがAPIアクセス委譲をどのように行っているのか、その仕組みをOAuthに関わる4つの役割とあわせて解説していきましょう。

アクセストークンと認可サーバ

Webサービスを利用していると、ユーザーが持つデータを別のアプリケーションで再利用したい場合が出てきます。

この場合、別のアプリケーションがユーザーの持つデータを保管しているサービスに、データの利用をリクエストします。このリクエストを受けるのがサービスの「認可サーバ」です。

認可サーバはリクエストに対し、アクセスを許可する認可情報であるアクセストークンの発行をして良いかユーザーに確認し、確認が取れればアプリケーションにアクセストークンを発行します。

リソースサーバとクライアントアプリ

ユーザーがデータを再利用したい別のアプリケーションを「クライアントアプリ」といいます。

アクセストークンを受取ったクライアントアプリは、ユーザーのデータが保管されている「リソースサーバ」へ、データ使用のリクエストとともにアクセストークンを渡します。

リクエストとアクセストークンを受取ったリソースサーバは、アクセストークンの信頼性を検証し、問題がなければデータをクライアントアプリへ渡します。

Instagramの例で置き換えると、ユーザーの写真が保管されている「リソースサーバ」、アクセストークンの発行を行う「認可サーバ」がInstagram内にあり、「クライアントアプリ」がFacebookになるという仕組みです。

OAuth認可の流れ

具体的にOAuthの認可がどのように行われるのか、ステップごとに解説していきます。

クライアント登録

ユーザーがOAuthを利用してサービス間の共有を行うため、まずクライアントアプリを認可サーバに登録する必要があります。

OAuthの規格では、登録方法などは指定していませんが、Facebookの場合は「developers.facebook.com」というデベロッパーサイトで行うようになっており、一度登録が完了すれば次回以降は登録の必要はなくなります。

認可フロー開始

クライアントアプリがリソースサーバからデータを受け取るには、ユーザーからAPIアクセス譲渡を受ける必要があることは解説しました。

多くの場合、クライアントアプリ側に「Facebookでログイン」というボタンが実装されており、ユーザーがこれをクリックすることによってAPIアクセス権譲渡の認可フローが開始されます。

認可のリクエスト

認可フローが開始されると、クライアントアプリは自身の識別情報とともに、認可サーバへAPIアクセス権譲渡リクエストをリダイレクトします。

クライアントアプリがリクエストに自身の識別情報を添える理由は、登録されたクライアント情報とリクエストとの適合を認可サーバが行うためであり、このため事前のクライアントアプリ登録が必要になります。

ユーザー認証

リクエストを受けた認可サーバは、ユーザー認証を行った上で、クライアントアプリへのAPIアクセス権譲渡を認可するか、ユーザーに確認を行います。

この確認方法もOAuthの規格では指定されていませんが、ID／パスワード入力やCookieを使用した認証方法が主流になっているようです。

Cookieについては以下の記事もご覧ください。

アクセストークン発行、認可レスポンス

ユーザーがAPIアクセス権譲渡を許可すると、認証サーバは、グラントというAPIへのアクセス権限付与情報を含むトークンとともに、クライアントアプリへリダイレクトを行います。

クライアントアプリの種類や、OAuthのバージョンによっては、グラントにアクセストークン自体が含まれる場合もあります。

クライアントアプリがAPIへアクセス

グラントを受取ったクライアントアプリは、リソースサーバAPIへグラントとともにデータ使用をリクエストします。

リソースサーバAPIはグラントを確認し、問題なければグラントと交換したアクセストークンとともにデータをリダイレクトします。グラントにアクセストークンが含まれている場合は、この交換が省略されます。

OAuth 2.0の課題

OAuth 2.0は、Webサービス間の共有を簡単にするプロトコルですが、RFCとして発行されていることからもわかるように、発展途上の規格であるといえます。

このため、1.0から多数の修正が行われた2.0でも解決すべき課題があります。

仕様の標準化が必要

OAuthでAPIアクセス権譲渡を行う場合には、クライアントアプリに対してのAPIアクセス権譲渡方法および、どの範囲までアクセスを許可するかを決定する「スコープ」の定義を行わなければなりません。

また、これらはクライアントアプリごとに行う必要もあります。

しかし認可の流れでも解説したように、OAuthの規格には、APIアクセス権譲渡方法の指定やスコープの定義は含まれていません。

このため、APIアクセス権譲渡によってユーザー情報が流出してしまう危険性があり、OAuth 2.0の仕様標準化が求められています。

OAuthを完全に信頼しない

OAuthは、Webサービス間の認証を行い、共有を簡単にするプロトコルではありますが、ユーザーの認証を行うために設計されたプロトコルではありません。

APIアクセス権譲渡をされたクライアントアプリが取得・保持したユーザー情報が流出し、アカウントの乗っ取りなどが起こってしまうのはこのためです。

このような認証の脆弱性を理解せずに、OAuthを実装しているWebサービスやアプリケーションも多く、中にはOAuth 1.0を実装したため、大量のユーザーデータが流出してしまったという事例もあります。

これを回避するためには、ユーザーがOAuthの機能や用途を正確に理解し、安易にOAuthによるAPIアクセス権譲渡を許可しないことが重要です。

BOXILとは

BOXIL（ボクシル）は企業のDXを支援する法人向けプラットフォームです。SaaS比較サイト「BOXIL SaaS」、ビジネスメディア「BOXIL Magazine」、YouTubeチャンネル「BOXIL CHANNEL」を通じて、ビジネスに役立つ情報を発信しています。

BOXIL会員（無料）になると次の特典が受け取れます。

• BOXIL Magazineの会員限定記事が読み放題！
• 「SaaS業界レポート」や「選び方ガイド」がダウンロードできる！
• 約800種類のビジネステンプレートが自由に使える！

BOXIL SaaSでは、SaaSやクラウドサービスの口コミを募集しています。あなたの体験が、サービス品質向上や、これから導入検討する企業の参考情報として役立ちます。

BOXIL SaaSへ掲載しませんか？

• リード獲得に強い法人向けSaaS比較・検索サイトNo.1^※
• リードの従量課金で、安定的に新規顧客との接点を提供
• 累計1,200社以上の掲載実績があり、初めての比較サイト掲載でも安心

^{※ 日本マーケティングリサーチ機構調べ、調査概要:2021年5月期 ブランドのWEB比較印象調査}