OAuthって何?パスワードを渡さずに連携する仕組み

OAuthは「合鍵を渡す仕組み」

OAuth(オーオース)は、あるサービスに対して自分のパスワードを教えることなく、別のサービスからのアクセスを許可するための仕組みです。ウェブやアプリの世界では、もうほとんど当たり前のように使われています。

たとえば、初めて使うアプリの登録画面で「Googleでログイン」「GitHubでログイン」というボタンを見たことはないでしょうか。あれを押すと、見慣れたGoogleやGitHubの画面に飛び、「このアプリにあなたのメールアドレスへのアクセスを許可しますか?」と聞かれます。許可すると元のアプリに戻ってきて、ログインが完了している。あの一連の流れが、まさにOAuthです。

ホテルのバレーパーキングに例えると

高級ホテルの車寄せで、係の人に車を預けるところを想像してください。このとき、多くのホテルでは「バレーキー」という専用の鍵を渡します。このバレーキーはエンジンをかけて駐車場まで動かすことはできますが、トランクは開かないし、グローブボックスもロックされたまま。走行距離にも制限がかかっているものもあります。

OAuthがやっているのは、これとほぼ同じことです。自分の家の鍵束(=パスワード)をまるごと渡すのではなく、「この用途に、この範囲だけ」という限定された鍵を発行して渡す。しかも、気に入らなければあとから「あの鍵はもう無効」と取り消せます。

なぜパスワードを直接渡してはいけないのか

OAuthが生まれる前は、たとえば「アドレス帳を読み込んで友達を探す」という機能のために、アプリがユーザーにGmailのパスワードを直接入力させる、みたいなことが実際に行われていました。今考えるとかなり怖い話です。

パスワードを直接渡してしまうと、いくつも問題が起きます。

• 渡した相手が、本来必要のない操作(メールの削除など)まで自由にできてしまう
• 渡した相手のサーバーが攻撃されたら、パスワードごと漏れる
• 「あのアプリだけ連携を切りたい」と思っても、パスワードを変えるしかない。すると他の連携も全部切れる

OAuthはこの3つを同時に解決します。範囲を限定でき、パスワードそのものは渡らず、個別に取り消せる。

登場人物と流れ

OAuthの説明にはいくつか役割が出てきますが、身近な言葉に置き換えると難しくありません。

役割	ざっくり言うと	例
ユーザー	データの持ち主で、許可を出す人	あなた
クライアント	アクセスさせてほしい側のアプリ	使いたいツール
認可サーバー	「許可しますか?」と聞いて鍵を発行する係	Googleのログイン画面
リソースサーバー	実際にデータを持っている場所	Googleのカレンダー

実際の流れは、だいたいこんな順番で進みます。

ここで出てくるアクセストークンが、さっきのバレーキーにあたるものです。ランダムな文字列で、これ自体にはパスワードの情報は入っていません。有効期限があり、期限が切れたら使えなくなります。

「スコープ」という考え方

許可画面に出てくる「このアプリは以下へのアクセスを求めています」という一覧、あれがスコープです。「メールアドレスの読み取りだけ」「リポジトリの読み書き」といった単位で権限が区切られています。

正直なところ、この画面をちゃんと読まずに「許可」を押してしまう人は多いです。でもここは目を通す価値があります。単なるログイン目的のはずなのに「あなたのファイルをすべて削除する権限」を求めてくるアプリがあったら、それは立ち止まるべきサインです。

「ログイン」との違い

ややこしいのですが、OAuthは本来認可(何をしてよいかを決めること)の仕組みであって、認証(この人が誰かを確かめること)そのものではありません。

実際には「〜でログイン」の形で認証っぽく使われる場面が多いので、両者が混ざって語られがちです。仕組みとして区別されている、ということだけ頭の片隅に置いておくと、後々の理解が楽になります。

使う側として気をつけたいこと

許可画面が出たとき、まずURLがちゃんと本物のサービスのものかを確認してください。偽の許可画面でパスワードを入力させる手口があります。それと、過去に許可したアプリは各サービスの設定画面から一覧で確認・取り消しができます。使わなくなったサービスの連携が何年も生きたまま、というのは珍しくないので、たまに見直すと安心です。