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