目次

はじめに

誰に向けた本か
この本を読むメリット
この本の特徴
この本は何の本ではないか
用語の定義
免責事項
表記関係について
底本について

第1章 はじめに

1.1 OAuthとはなにか
1.2 OAuthはなぜ必要か

第2章 OAuthのロール

2.1 リソースオーナー
2.2 クライアント
2.3 リソースサーバー
2.4 認可サーバー
2.5 4つのロールの関係

第3章 OAuthのトークン

3.1 アクセストークン
3.2 リフレッシュトークン
3.3 認可コード

第4章 OAuthのエンドポイント

4.1 認可エンドポイント
4.2 トークンエンドポイント
4.3 リダイレクトエンドポイント(リダイレクトURI)

第5章 OAuthのグラントタイプ

5.1 クライアントの登録
5.2 認可コードグラント
5.3 インプリシットグラント
5.4 クライアントクレデンシャルグラント
5.5 リソースオーナーパスワードクレデンシャルグラント
5.6 リフレッシュトークンによるアクセストークン再発行
5.7 認可コードグラント + PKCE

第6章 チュートリアル

6.1 クライアントの登録
6.2 認可コードグラント
6.3 認可コードグラント + PKCE
6.4 インプリシットグラント

付録A OAuth認証について

A.1 認証のためのプロトコルという誤解
A.2 OAuth認証の仕組み

付録B S256でのcode_challengeの算出

付録C OAuth関連用語の英語と日本語の対応

あとがき

お問い合わせ
謝辞

はじめに

 本書を手にとっていただき、ありがとうございます。あなたにとってOAuth2.0の理解を深めるきっかけとなれば幸いです。

誰に向けた本か

 「ぜんぜんわからない。俺たちは雰囲気でOAuthをやっている。」1または「OAuthまわりはライブラリーにまかせているので、パラメーターを設定するくらいしかやっていない。どんなやりとりが行われているのかわかってない。」というエンジニアに向けてこの本を書きました。具体的には、次の質問に答えられないエンジニアです。

 ・スコープとはなんですか?

 ・認可コードは何が行われた証ですか?

 ・サーバーサイドのアプリケーションの場合、どのグラントタイプを使うべきですか?

この本を読むメリット

 ・OAuth2.0に関わる概念を整理して理解できます。

 ・具体的なソフトウェアプロジェクトの構成要素をOAuth2.0のロールにマッピングできるようになります。

 ・自分のソフトウェアプロジェクトで利用すべきグラントタイプを判断できるようになります。

 ・利用したいAPIのOAuth関連資料やOAuth2.0の標準仕様を読みこなすための地図が頭の中にできます。

この本の特徴

 ・Google PhotoのAPIを使った画像編集アプリの例を頻繁に挙げることで、具体的にイメージしやすい説明を試みています。

 ・チュートリアルの章では、実際に手を動かしながら学べます。

 ・OAuthの仕様で決められているオプションについては網羅的に説明するのではなく、オーソドックスな一つの例を基に説明しています。

この本は何の本ではないか

 ・この本はOpenID Connectについては説明していません。OAuth2.0とOpenID Connectを並行して学ぶと混乱するからです。 まずはOAuth2.0についてしっかりと理解し、その後、OpenID Connectとの差分を理解する、というのがOAuth2.0とOpenID Connectの両方を理解するの最短の道だと考えています2

 ・この本はOAuth1.0と2.0の違いについては説明していません。

 ・この本はOAuth2.0に関する攻撃手段についてはほとんど説明していません。3

用語の定義

 本書で用いる用語について次のように定義します。

OAuth

 OAuth2.0のことです。本書ではOAuth1.0は含みません。2章以降ではOAuthと記載したときはOAuth2.0を意味します。

標準仕様

 本書ではRFC6749(https://tools.ietf.org/html/rfc6749)のことです4

免責事項

 本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

表記関係について

 本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。

底本について

 本書籍は、技術系同人誌即売会「技術書典6」で頒布されたものを底本としています。

1. この表現の元ネタは「【株の知識ゼロ】バカが考えた株の漫画 」です。https://orekabu.jp/bakakabu/

2. 技術書典7で出す本で説明する予定です。

3. 技術書典8で出す本で説明する予定です。

4. OpenIDファウンデーション・ジャパンにより日本語訳が提供されています。https://www.openid.or.jp/document/index.html#op-doc-oauth2

第1章 はじめに

 この章では「OAuthとは何か」「なぜOAuthが必要なのか」について説明します。

1.1 OAuthとはなにか

 OAuthとは何でしょうか。OAuthの標準仕様であるRFC6749をみてみましょう。アブストラクトの最初の一文が端的にOAuth2.0とは何かを表しています。

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service,

 日本語に翻訳すると次の内容になります1

OAuth2.0はサードパーティアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである。

 ここに含まれている次の4つの言葉の意味をOAuthの文脈にそって理解すれば、「OAuthとは何か」を理解したことになります。

 ・サードパーティアプリ

 ・HTTPサービス

 ・限定的なアクセス

 ・認可フレームワーク

 ここでは、ある画像編集アプリケーションを例としてこれらの用語を説明します。この画像編集アプリは、画像をGoogle Photoから取得する機能を持っています。定義に登場した用語と画像編集アプリの例の対応を図1.1に示します。

図1.1: 画像編集アプリの構成要素

 4つの言葉をこの例にそって解説します。

サードパーティアプリ

 画像編集アプリが「サードパーティーアプリ」に対応します。Google PhotoのAPIを提供するGoogleからみるとサードパーティだからです。

HTTPサービス

 この例ではGoogle PhotoのAPIが「HTTPサービス」に当たります。

限定的なアクセス

 画像編集アプリはGoogle PhotoのAさんのデータに対してどんな操作でも許されているわけではありません。許されるのは画像のダウンロードのみです。仮に画像編集アプリが画像のアップロードや、画像の削除をしようとした場合はGoogle Photoはそのアクセスを拒否しなければなりません。このようにサードパーティはHTTPサービスに対して一部の操作のみが許されます。


 ところで、Google Photoは許可してよい操作をどのように知るのでしょうか。それはAさんの同意によります。OAuthでは「Google Photoにある写真やアルバムなどのデータはAさんのものである。Google Photoのものではない。」と考えます。したがって、画像編集アプリによるAさんのデータへの操作をGoogle Photoが勝手に許可してはいけません。

 画像編集アプリが要求する権限一覧をAさんに提示した上で、Aさんから権限の委譲について同意を得る必要があります。その同意が完了してはじめて、Gooole Photoは画像編集アプリに許可して良い操作を知ることができます。

認可フレームワーク

 Google PhotoのAPIはインターネットに公開されているので悪意あるアクセスを前提としなければなりません。Google Photoはすべてのアクセスに対して、許可してよいアクセスかどうかを判断します。この判断に使われるのがアクセストークンです。認可フレームワークとは「アクセストークンの発行方法についてのルール」といえます。そして、このルールにそってアクセストークンを払い出すのが、GoogleのOAuthサービスになります。

 各用語の説明が終わったので、もう一度定義に戻りましょう

OAuth2.0はサードパーティアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである。

 これを例に沿って言い換えると次のとおりです。

OAuth2.0は「画像編集アプリによるGoogle Photoへの限定的なアクセス(Aさんの領域へのアップロードのみ)」を可能にするための「アクセストークンの発行方法のルール」である。

試し読みはここまでです。
この続きは、製品版でお楽しみください。