OAuth徹底入門の読書感想文 -5章-
OAuth徹底入門を読んだので感想と概要を書いていきます
4章については先日書きました
シンプルなOAuthの認可サーバーの構築
3章でクライアントを、4章で保護対象リソースの実装をしましたが、5章では認可サーバーの実装をしながら認可サーバーの役割について細かく解説してあります
この章も読むだけでも十分勉強になります
認可サーバーの役割
認可サーバーのやることは主には以下の4つ
クライアントの登録管理
認可サーバーでは権限委譲をリクエストしているクライアントの認証を行う必要がある
認可サーバーではクライアントIDとクライアント・シークレットをクライアントに対して発行し、それを用いてクライアントの認証を行う
クライアントの認可
クライアントは権限委譲を行う際、ユーザーを認可サーバーの認可エンドポイントへリダイレクトする
認可エンドポイントではクライアントの認証を行い、ユーザーに認可ページを表示する
ユーザーがクライアントを認可すると、認可サーバーは認可コードを発行し (認可コードによる付与方式を採用している場合に限る)ユーザーをクライアントへリダイレクトする
認可コードはアクセストークン発行の際に必要になるので、クライアントIDと紐づけて認可サーバー側で保存しておく
トークンの発行
クライアントは認可コードを受け取ると、アクセストークンを発行してもらうため認可サーバーへリクエストを送信する
クライアントを認証し、受け取った認可コードが正当なクライアントのものであることが確認できたらアクセストークンを発行し、クライアントへ送信する
その際、認可コードが有効であることが確認できたらすぐに保存していた認可コードを削除する
そうすることで悪意あるクライアントにより認可コードが盗まれた際のリスクを減らすことができる
リフレッシュトークン、スコープのサポート
リフレッシュトークン
アクセストークンの発行と同様にリフレッシュトークンの発行も行うことができる
認可サーバーはアクセストークン発行の際に同時にリフレッシュトークンも発行してクライアントへ送信する
アクセストークンとリフレッシュトークンはクライアントIDと紐づけて保存しておく
クライアントはアクセストークンが期限切れの場合、リフレッシュトークンを認可サーバーへ送信する
認可サーバー側でクライアントとリフレッシュトークンの組み合わせが正しいことが確認できたら、新たなアクセストークンとリフレッシュトークンをクライアントへ送信する
古いトークンは破棄し、新たに発行したトークンとクライアントIDを紐づけて認可サーバー側に保存しておく
スコープ
認可サーバー側で、クライアントがどのスコープにアクセスできるかをあらかじめ登録しておく
さらにクライアントからリクエストを送る際にも、どのスコープを必要とするかをパラメータとして含めて送信する
クライアントに許されたスコープと、クライアントが要求しているスコープが異なる場合は認可サーバーはエラーを返す
スコープが正しい場合は認可コードにスコープの情報を含めてクライアントへ送信する
クライアントは認可コードを送信し、スコープの情報がついたアクセストークンを取得する
保護対象リソースでは、アクセストークンのスコープの情報を解析し、アクセスを許可するリソースを決定する
感想
当たり前だけど認証、認可を担っているので認可サーバーはクライアントや保護対象リソースよりやることが多くて複雑
フロント・チャネル (ユーザーが認可を行う)とバック・チャネル (クライアントがアクセストークンを取得する)のコミュニケーションは認可コードを発行するかアクセストークンをするかの違いくらいしかなさそうと思ってたけど、確認するスコープや受け取る情報の取り出し方など違いが結構ある
