LASSIC Media らしくメディア
OAuth入門｜外部サービス連携の認可の仕組み
Webサービスで「Googleで続ける」「他のアカウントで連携する」といったボタンを見かける機会が増えました。新しくIDとパスワードを作らなくても、すでに使っている別のサービスと結びつけて、ログインしたりデータを取り込んだりできる——その裏側で働いているのがOAuthという仕組みです。
OAuthは、あるサービスに預けている自分のデータへのアクセスを、パスワードを渡すことなく別のサービスへ許可するための取り決めです。ソーシャルログインや、外部サービスとのデータ連携を支える土台として、いまや欠かせません。この記事では、発注者やプロジェクトマネージャー、これからWeb開発に関わる方に向けて、OAuthの登場人物と認可の流れ、そして開発・発注の現場でおさえておきたい注意点を整理していきます。
OAuthとは何か
OAuthとは、利用者が持っているデータやサービスへのアクセスを、パスワードを共有せずに、別のアプリケーションへ限定的に許可するための仕組みです。「認可（アクセスを許す）」の委譲を扱う取り決めであり、現在広く使われているのはOAuth 2.0と呼ばれる版です。
たとえば、写真印刷のサービスが「あなたのクラウド上の写真を取り込みます」と案内する場面を思い浮かべてみましょう。ここでクラウドのIDとパスワードを印刷サービスに直接教えてしまうと、写真以外のすべてに手が届く鍵を渡すことになりかねないのです。OAuthを使えば、パスワードは渡さずに「写真を読む許可だけ」を印刷サービスへ与えられます。合鍵を丸ごと預けるのではなく、特定の部屋にだけ入れる一時的な通行証を発行するイメージです。
この「必要な範囲だけを、パスワードなしで許可する」という考え方が、OAuthの核心にあります。許可の範囲は絞り込めますし、後から取り消すこともできます。だからこそ、外部サービスとの連携やソーシャルログインの土台として、広く採り入れられているのです。
この記事のポイント
- OAuthは、パスワードを渡さずに、データへの限定的なアクセスを別のアプリへ許可する仕組みです。
- 利用者・クライアント・認可サーバー・リソースサーバーの4者が、トークンを介して連携します。
- OAuthは「認可」の仕組みで、本人確認の「認証」とは役割が異なる点に注意が要ります。
4つの登場人物
OAuthの流れを理解するには、まず登場する4者の役割を押さえるのが近道です。それぞれが何を担うのかを整理しました。
| 登場人物 | 役割 |
|---|---|
| リソースオーナー | データの持ち主である利用者。アクセスを許可する立場 |
| クライアント | データを使いたいアプリ。利用者に代わってアクセスを求める |
| 認可サーバー | 利用者の同意を確かめ、アクセスの許可証（トークン）を発行する |
| リソースサーバー | データを預かる側。トークンを確認してアクセスに応じる |
先ほどの写真印刷の例でいえば、リソースオーナーはあなた、クライアントは印刷サービス、認可サーバーとリソースサーバーはクラウドの写真サービス側にあたります。ここで発行される「トークン」が、パスワードの代わりとなる一時的な通行証です。クライアントはこのトークンを提示することで、許された範囲のデータにだけアクセスできます。
認可の流れ（認可コードフロー）
OAuthにはいくつかの流れ方（フロー）が定められていますが、Webサービスで広く使われる基本形が「認可コードフロー」です。少し細かく見えますが、順を追えば筋道はわかりやすいものです。下の図で流れを追ってみましょう。
まず利用者がクライアントで「連携する」を選ぶと、認可サーバーの同意画面へ案内されます。利用者がそこで「この範囲を許可する」と同意すると、認可サーバーは「認可コード」と呼ばれる一時的な引換券をクライアントへ渡すのです。クライアントはその引換券を、自分だけが知る情報とあわせて認可サーバーへ送り、「アクセストークン」と交換します。以降、クライアントはこのアクセストークンを提示して、リソースサーバーの許された範囲のデータにアクセスするわけです。
ポイントは、利用者のパスワードがクライアントの手に渡らないところにあります。やり取りされるのは、範囲と期限が定められたトークンだけです。トークンには寿命が設けられており、期限が切れても「リフレッシュトークン」という別の仕組みで再発行できるため、利用者が何度も同意し直す手間も抑えられます。
OAuthでできること・注意点
OAuthを使うと、パスワードを共有せずに外部サービスとの連携を組み立てられます。一方で、役割を取り違えると思わぬ穴を生むため、いくつか注意しておきたい点があります。
まず、もっとも大切な注意点は、OAuthは「認可」の仕組みであって、「認証（本人確認）」そのものではないということです。OAuthが答えるのは「このアプリに、この範囲のアクセスを許してよいか」であり、「この人が誰なのか」を確かめる役目は本来別にあります。ソーシャルログインのように本人確認まで行いたい場合は、OAuthを土台にした OpenID Connect という別の仕組みを組み合わせるのです。ここを混同すると、認証の設計に穴が生まれかねません。
次に、許可する範囲を表す「スコープ」を絞ることが挙げられます。連携のために必要な範囲だけを求め、過剰な権限を要求しないことが、万一トークンが漏れたときの被害を小さくします。加えて、認可の途中で悪用を防ぐ仕掛け——たとえば、なりすましのリクエストを見分けるための state と呼ばれる値の確認や、トークンを受け取る戻り先アドレスの厳密な照合なども、あわせて押さえておきたいところです。これらは、以前取り上げたクロスサイトリクエストフォージェリやオープンリダイレクトへの備えとも地続きになっています。
発注・開発でおさえる点
OAuthは仕様が細かく、独自に作り込もうとすると穴が生まれやすい領域です。発注や設計の段階で意識しておきたい点を挙げます。
自前で作らず、実績ある仕組みに任せる
認可サーバーの機能を一から自作するのは負担が大きく、抜けも生まれがちです。多くの場合、外部のID基盤（IDaaS）や、実績のあるライブラリを用いるほうが、無理がありません。「認可の仕組みは標準の実装に任せる」という方針を早めに決めておくと、設計の判断がぶれにくくなります。
スコープと連携先を要件に落とし込む
「どの外部サービスと、どのデータを、どの範囲で連携するのか」を、要件として整理しておきます。求めるスコープが必要最小限になっているかは、発注する側からも確認したい観点です。過剰な権限は、利用者の不安にもつながります。
戻り先アドレスとトークンの扱いを点検する
認可の後にトークンを受け取る戻り先アドレスは、あらかじめ登録したものと厳密に一致するよう確かめます。また、受け取ったトークンをどこに保管し、いつ捨てるのかも設計の対象です。これらの点検は、公開前のテスト項目に含めておくと見落としを防げます。
よくある誤解と勘所
OAuthは言葉が独特で、役割の誤解が起こりやすいテーマです。代表的なつまずきを表にまとめました。
| よくある誤解 | 実際のところ |
|---|---|
| OAuthでログイン＝本人確認 | OAuthは認可の仕組み。本人確認はOpenID Connectなどが担う |
| トークンとパスワードは同じ | トークンは範囲と期限が絞られた通行証。漏れても影響を限定できる |
| スコープは広く取ると便利 | 広いほど漏えい時の被害も大きい。必要最小限が原則 |
| 自前で作れば柔軟にできる | 仕様が細かく穴が生まれやすい。標準の実装に任せるほうが堅実 |
勘所は、OAuthを「パスワードを渡さずに、必要な範囲の鍵だけを貸し出す仕組み」として捉えることです。そのうえで、貸し出しているのはあくまでアクセスの許可であって、本人確認とは別だと切り分けておくと、設計の見通しが立てやすくなります。範囲を絞り、戻り先を確かめ、実績ある実装に任せる——この三点を外さないことが、堅実な連携につながっていきます。
まとめ
- OAuthは、パスワードを渡さずに、データへの限定的なアクセスを別のアプリへ許可する仕組みである。
- リソースオーナー・クライアント・認可サーバー・リソースサーバーの4者が、トークンを介して連携する。
- 基本形の認可コードフローでは、同意→認可コード→トークン交換→アクセスの順で許可が渡る。
- OAuthは「認可」の仕組みで、本人確認の「認証」はOpenID Connectなどが担う。
- スコープの最小化、戻り先アドレスの照合、実績ある実装の活用が、堅実な連携の勘所。
よくある質問
OAuthと認証は何が違うのですか。
役割が異なります。OAuthが扱うのは「認可」、つまり「このアプリに、この範囲のアクセスを許してよいか」という許可の委譲です。一方「認証」は「この人が本人かどうか」を確かめる行為で、OAuth単体はそこを保証するものではありません。ソーシャルログインのように本人確認まで行いたい場合は、OAuthを土台にしたOpenID Connectという仕組みを組み合わせます。両者を切り分けて捉えることが、設計での取り違えを防ぐうえで大切です。
OAuthとJWTはどういう関係ですか。
別の層の話で、組み合わせて使われることが多い関係です。OAuthは「どうやってアクセスの許可を受け渡すか」という枠組みを定めます。一方JWTは、その中でやり取りされるトークンの表現方法の一つです。OAuthで発行されるアクセストークンの中身がJWTの形式になっていることもありますが、必須ではありません。OAuthが流れの取り決め、JWTがトークンの形式、と層を分けて捉えると整理しやすくなります。
スコープとは何ですか。なぜ絞る必要があるのですか。
スコープは、クライアントに許すアクセスの範囲を表す指定です。たとえば「写真を読む」「連絡先を読む」といった単位で、許可する範囲を細かく定められます。広い範囲を求めるほど連携で使える情報は増えますが、その分、万一トークンが漏れたときに悪用される範囲も広がります。そのため、連携に本当に必要な範囲だけを求めるのが原則です。利用者にとっても、求められる権限が最小限であれば、同意の判断がしやすくなります。
OAuthの仕組みは自前で作るべきですか。
多くの場合、自前での作り込みはおすすめしません。OAuthは仕様が細かく、戻り先アドレスの検証や状態の確認など、押さえるべき点が多いため、独自実装では穴が生まれやすいのが実情です。外部のID基盤（IDaaS）や、広く使われている実績のあるライブラリを用いるほうが、抜けを防ぎつつ開発の負担も抑えられます。要件に特別な事情がない限りは、標準の実装に任せる方針が堅実といえます。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、認証・認可の要件整理から設計・実装、公開済みシステムの点検・改修までを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。OAuthやソーシャルログイン、外部サービス連携の設計でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
