RFCを読もう

業務でAPI GWの認証認可部分を担当することになった。 引継ぎ元となる先輩に認証認可の入門書のオススメを聞いたところ、 「世の中の入門書は中級者向けだから、RFC読めばいいよ」という、お言葉をいただいた。

そこで、はじめてRFCを読むわけだが、 人目見ただけで分量に嫌気が差した。

世の中には簡単に説明している記事はあるが、読みたいのはあくまでRFC。 そこで、あくまでRFCの記載内容にしたがって、簡単に要約してみる。

今回はRFC6749を読むことにする。 なお、実装にあたっては厳密性が重要になるため、原文（もちろん英語版）で理解することが前提とのこと。

1.はじめに

要約と言いつつ、さっそく銀行と通帳アプリで例えることにする。

通帳アプリに銀行のパスワード教えるのはいまいちだよね。 なぜなら

  • 通帳アプリが利用者本人とまったく同じ権限使えるよね。
  • 利用者が通帳アプリを複数使っていた場合、アプリごとに利用を停止できない。パスワード変更すれば停止できるけど、全部利用止まっちゃうよね。
  • 通帳アプリの情報漏洩が問題だよね。 という理由。

そこで、権限移譲用の別のトークンを用意しよう！

1.1登場人物

登場人物は以下の4種類。

  • リソースオーナー：通帳アプリの利用者（個人情報のオーナーってイメージ）
  • リソースサーバ：銀行のサーバ。
  • クライアント：通帳アプリ
  • 認可サーバ ：通帳アプリにトークンを発行するサーバ 。銀行のサーバと同じでもいいし、違うかもしれない。

1.2プロトコルフロー

プロトコルフローは大きく分けると3つの工程で成り立っている。

  1. クライアントとリソースオーナーのやりとり。

    クライアントは認可を要求し、認可グラントを受け取る。

  2. クライアントと認可サーバのやりとり。

    クライアントは認可グラントを提示し、アクセストークンを受け取る。

  3. クライアントとリソースサーバのやりとり。

    クライアントはアクセストークンを提示し、リクエストが成立する。

1.3認可グラント

ここからは用語の説明。

認可グラントは、リソースオーナーが認可したことを表すものだよ。 グラントタイプは4種類。

  • 認可コード
  • インプリシット
  • リソースオーナーパスワードクレデンシャル
  • クライアントクレデンシャル

それぞれ説明します。

1.3.1認可コード

認可サーバが発行する秘密の文字列。

クライアントはリソースオーナーを認可サーバにリダイレクトする。 認可サーバ上で認証されたら、認可コードとともにリダイレクトされて、戻ってくる。

セキュリティ的にgood.

1.3.2インプリシット

認可グラントを渡さず、直接アクセストークンをクライアントに返す。

認可コードフローを短縮したもの。そもそも上で説明した認可コードフローと違うことをやってる。

1.3.3リソースオーナーパスワードクレデンシャル

IDとパスワードのようなもの。

はじめにで記載されているイマイチな例。 ただし、クライアントがOSの一部の場合はいいんじゃないか、ということ。

1.3.4クライアントクレデンシャル

秘密の文字列。

あらかじめクライアントと認可サーバの間で取り決めておく。 認可範囲がクライアントの管理かである場合に使う。

1.4アクセストークン

秘密の文字列。リソースへアクセスする際に使う。

1.5リフレッシュトークン

オプションの項目。 期限が切れたアクセストークンの代わりに、新しいアクセストークンをもらうために利用することができる。

アクセストークンの有効期限が切れるたび認可グラントを提示するのはセキュリティリスクが高まる。 リフレッシュの際には、専用のトークンを利用することで、認証情報のやりとりを減らすことができる。

リフレッシュトークンを利用する流れは以下の通り。

  1. クライアントと認可サーバのやりとり（認可フローの2に相当）

    認可グラントを提示して、アクセストークンとリフレッシュトークンを受け取る。

  2. クライアントとリソースサーバのやりとり（認可フローの3に相当）

    クライアントはアクセストークンを提示して、リソースへアクセスする。 有効期限が切れていたら、エラーを返して無効であることを伝える。

  3. クライアントと認可サーバのやりとり

    クライアントはリフレッシュトークンを提示して、新しいアクセストークンを受け取る。

1.6〜1.9

割愛