OAuth2.0のメモ
auth認可(Authorization)と認証(Authentication)
それぞれAuthZ、AuthNとも書かれる。
- 認可: リソースへのアクセスを許可する
- 認証: ユーザーが何者かを検証する
OAuth 2.0
認可のプロトコル。 それによってアクセスできるようになったリソースの情報をもとに認証を行ったりすることもあるが、 以下に示すImplicit Flowでそれをやると他のサービスのトークンで他人に成りすませてしまう問題があるため、 認証する場合はOAuth 2.0ベースの認証プロトコルのOpenID Connectを使うべき。 その場合もトークンを取得するまでの流れはほとんどOAuth 2.0通りなのでフローを理解しておいて無駄はない。
OpenID ConnectのIDトークンの内容と検証 - sambaiz-net
Authorization Code Flow
OAuthクライアントがアプリケーションサーバーのときのフロー。
まずユーザーがOAuth認可ページで認可する。 このリクエストには
- client_id
- redirect_uri
- scope: アクセスできるリソースの種類
- response_type=code: 認可コードが返される
- state: CSRFを防ぐためのランダムで一意な文字列。アプリケーションサーバーが保持して、前後で一致するかチェックする
が含まれる。
認可されると認可コードとstateを付けてredirect_uri(事前に登録しておく)にリダイレクトするので、 アプリケーションサーバーは認可コードをアクセストークンに交換する。 この際、client_idとclient_secretも送る。
オプションでリフレッシュトークンを含み、これを使うと期限が切れたとき新しいアクセストークンを取得できる。
アクセストークンは通常Bearer Token(Authorization: Bearer ***)としてリクエストに含まれる。
Implicit Flow
OAuthクライアントがアプリなどでclient_secretの機密性を保てない場合のフロー。
認可コードは不要なのでresponse_type=tokenでリクエストし、アクセストークンをブラウザで取得する。
リフレッシュトークンは含まない。
他のサービスで発行された他人のトークンを使うことでなりすませてしまうので、
そのトークンがどのサービスに対して発行されたかを確認する術が特に用意されているのでなければ
認証に使ってはいけない。OpenID Connectでは署名されたIDトークンに発行されたサービスの情報が含まれている。