OAuth2.0のメモ

(2017-01-08)

認可(Authorization)と認証(Authentication)

それぞれAuthZ、AuthNとも書かれる。

  • 認可: リソースへのアクセスを許可する
  • 認証: ユーザーが何者かを検証する

OAuth2.0

認可のプロトコル。 それによってアクセスできるようになったリソースの情報をもとに他のサービスが認証を行ったりしている。

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でリクエストし、アクセストークンをブラウザで取得する。 リフレッシュトークンは含まない。 これをそのまま認証に使うと、他のサービスで発行された他人のトークンを使うことでなりすませてしまうので、 そのトークンがどのサービスに対して発行されたかを確認する術が必要。

redirect_uriは事前に登録しておく必要がある。

参考

O’Reilly Japan - OAuth 2.0をはじめよう

Implicit Flow では Covert Redirect で Token 漏れるね - OAuth.jp