OAuth

概要

OAuthとは、運営主体の異なる複数のWebサイトやネットサービス、ソフトウェアなどの間で、データや機能へのアクセス権限の認可(authorization)情報を送受信するためのプロトコル(通信規約)の一つ。

ある利用者がネット上のサービスAとサービスBに加入しているとする。通常ならばAの機能や保管しているデータは利用者本人しかアクセスできないが、OAuthを用いると、Bに対して「自分がAで利用している機能やデータにアクセスしても良い」という許諾を与え、Aに対して「Bが自分についての操作やデータを求めてきたら提供しなさい」と指示することができる。

これにより、BではAが提供する機能やデータと連携したサービスを利用者に対して提供することができる。例えば、写真共有サービスに写真を投稿すると、利用者が操作しなくてもSNSの自分のアカウントにも自動的に投稿される、といった機能が実現できる。

OAuthではシステム間でアクセストークン（access token）と呼ばれる機能ごとに発行される短い符号を受け渡すことで権限の認可を行っており、利用者の認証情報そのものはやり取りしない。利用者はパスワードなど秘密の情報を渡すことなく、サービス同士を連携させることができる。

OAuth 2.0

最新の仕様であるOAuth 2.0では、上記の例におけるサービスAに相当するOAuthクライアント、利用者本人に相当するリソースオーナー、サービスBに相当する認可サーバとリソースサーバという4つの役割（ロール）が定義されている。

まずクライアントはリソースオーナーに認可要求（authorizaion request）を行う。実際の利用場面では利用者の求めに応じて認可プロセスが開始するため、クライアントが認可サーバに認可を求め、認可サーバがリソースオーナーに問い合わせを行う形になることが多い。

リソースオーナー（通常は利用者本人）はWebブラウザを操作して「サービスAに権限を与える」等の回答を行うことで認可グラント（authorization grant）をクライアントに与える。これも実際には認可サーバを経由して行われることが多い。

クライアントは認可サーバに認可グラントを送り、アクセストークンの発行を要求する。認可サーバはクライアントを認証し、正規の認可グラントであると確認できればアクセストークンを発行する。クライアントはリソースサーバにアクセストークンを示して資源の要求を行い、リソースサーバはトークンが真正であると確認できれば要求を受け入れる。

OAuthの仕様の範疇ではアクセストークンの具体的な形式や記述内容、認可サーバとリソースサーバの間の連携方式などは定めておらず、システムごとに独自に実装する。トークンの形式にはJWT（JSON Web Token）を用いることが多い。

OAuth認証

OAuthにより利用者の認証情報そのものをシステム間でやり取りし、他のサービスのIDでログインできるようにする「OAuth認証」を提供している事例もある。

利用者アカウントを取得しなくても著名SNSや大手ネットサービスなどのIDでサービスを利用できて便利だが、連携先に認証情報そのものを丸ごと渡してしまう形になるため、連携先に悪意がある場合なりすましや不正操作の被害に遭うほか、連携先のデータ管理が不適切で認証情報が流出するリスクにも晒される。

OAuthはそもそも認証のために用いるものではないため、外部IDによるログインなどを実装したい場合はOpenID ConnectなどのID連携のための仕組みを用いるべきであるとされる。

歴史

2000年代前半に「Web 2.0」概念の一環として外部のサービスの機能やデータを取り込んでサービスを構築する「マッシュアップ」の手法が広がり、異なる主体の運営するサービス同士を安全に連携させる標準的な手段の確立が課題となった。

2007年に米ツイッター（Twitter）社（当時）のブレイン・クック（Blaine Cook）氏らがOAuth 1.0の仕様を公表した。同氏らのグループは同時期にOpenIDの仕様策定も手掛けている。2010年頃に次世代のOAuthを策定する動きが活発になり、2012年にOAuth 1.0とは互換性のないOAuth 2.0がIETFによって標準化（RFC 6749およびRFC 6750）された。

(2023.10.14更新)