Weekly Log 6 -- 書評: 雰囲気で使わずきちんと理解する！ 整理してOAuth2.0を使うためのチュートリアルガイド --
認証・認可について理解する必要にかられたので、先日あったDMMの７割引セールの際に仕入れたOAuthの本を読んだ。
タイトルに書評と書いているが、実質読書メモ
第１章 はじめに
OAuth2.0とは？
RFC6749を引用すると
OAuth2.0はサードパーティアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可(Authorization) フレームワークである らしい。
すなわち、以下の４つを理解すればOAuth2.0が理解できると言っても過言ではない？ - サードパーティアプリ (画像編集アプリ等) - HTTPサービス (Google等) - 限定的なアクセス (一部写真の読み取り等） - 認可フレームワーク
なぜ必要か？
- サードパーティアプリにパスワードを教える必要がない、教えたくない
- 読み取りのみ許可したい
- 流出を防ぎたい
- HTTPサービス側からアクセス遮断するためにはパスワード変更しか無い
第２章：OAuthのロール
リソースオーナー
Google とかのユーザ リソースを持つ人
クライアント
認証情報（クライアントID,クライアントシークレット）をセキュアに保存できるかでタイプ分け - コンフィデンシャルクライアント - サーバーサイドWEBアプリ等 - パブリッククライアント - ブラウザWEBアプリ、ネイティブアプリ等
リソースサーバ
Web APIでリソースを提供
認可サーバ
- リソースオーナーの認証
- オーナーからの同意を得る
- アクセストークン発行
4つのロールの関係
第３章：OAuthのトークン
アクセストークン
スコープ
アクセス権コントロールの仕組み
Googleは https://www.googleapis.com/auth/photoslibrary.readonly のようにhttpsのURL形式だが、決まったフォーマットは無い
有効期限
トークンの有効期限
リフレッシュトークン
トークンの再発行に利用される。
仕様として必須項目ではない
認可コード
「リソースオーナーがクライアントへの権限移譲に同意した証」 認可サーバが生成しクライアントに送る。 クライアントはこれをもとにアクセストークンを得る 仕様では10分以内の有効期限を推奨
第４章：OAuthのエンドポイント
認可エンドポイント
認可サーバのエンドポイント 認可コードを発行する
トークンエンドポイント
認可サーバのエンドポイント クライアントが認可コード等の情報を元にアクセス アクセストークンを発行する
リダイレクトエンドポイント（リダイレクトURI）
クライアントのエンドポイント クライアントは認可サーバのリダイレクトにより認可コードをURLのクエリ文字列として受け取る
第５章：OAuthのグラントタイプ
４種類のグラントタイプ（権限付与のタイプ）がある
- 認可コードグラント
- インプリシットグラント
- クライアントクレデンシャルグラント
- リソースオーナーパスワードクレデンシャルグラント
基本は全てのタイプでクライアントの事前登録が必要
クライアントの登録
クライアントはリソース（サーバ）提供組織に登録し、クライアントID、クライアントシークレットの発行を受ける。 *1 クライアントの登録する情報の内特に重要なのは、リダイレクトURI
認可コードグラント
最重要＆最複雑 PKCEとペアで原則推奨 コンフィデンシャルクライアントに最適*2
インプリシットグラント
パブリッククライアント向け 現在は非推奨
クライアントクレデンシャルグラント
クライアント（兼オーナー）＆認可サーバのみのやり取り
リソースオーナーパスワードクレデンシャルグラント
オーナーのユーザー名＆パスワードがクライアントを通して認可サーバに送られる
リフレッシュトークンによるアクセストークン再発行
認可コードグラント＋PKCE
パブリッククライアントで推奨 PKCE(Proof Key for Code Exchange)：ピクシー
第６章：チュートリアル
略
感想
ピクシーという単語は聞いたことがあった気がするけど、PKCEと書くことは初めて知った。
ともあれ、
OAuth完全に理解した！...気がするだけ
