これはRICORA言語班 Advent Calendarの24日目の記事です。
背景
アルバイトで調べることになったため。
OAuth2.0に至る背景
HTTPはドキュメントの送受信とAPIへのアクセスを兼ねるが、ステートレスなのでAPIへの認証を提供していない。そこで、APIへの認証を適切に提供することで、クライアントが正しい権限でリソースにアクセスできるようにする機構が必要。そこで、リソースへのアクセスに対してアクセストークンを発行するという方式をとる。そのために、OAuthはトークンの取得方法と使用方法を定義する。
構成と前提
前提として、リソースの所有者（人類であってもよい）が、クライアントアプリに、認証が必要なリソースへのアクセスをさせたいとする。例えば、メールアドレスを付与されている個人がメールボックスに入っているメールを確認するためにクライアントアプリを通じてメールボックスのデータにアクセスしたい場合など。POP3でもIMAPでもいいが、基本的に人類は毎日温かみのあるcURLを書くわけではなく、サンダーバードちゃんなどにそこらへんを全部任せているので、クライアントを想定するのは必須である。
構成は以下の通り。
// 構成
Tokenの発行
認証が必要なリソースへのアクセスを考えると、とりあえずは以下のような手順を取ることになる。
- リソース所有者がクライアントに認証が必要なリソースへのアクセスを指示する
- クライアントは認可サーバーに問い合わせて、リソース所有者にクライアントを認可してもらう
- 所有者に認可されたクライアントは認可サーバーにトークンを発行してもらう
- クライアントはトークンをリソースに提示する
では認可のための、認可コードによる付与形式という機構を考えよう。クライアントアプリ側でリソース所有者による認可が必要だと判断したとき、以下のようなことが行われる。
- クライアントは所有者を認可サーバーの認可エンドポイントへリダイレクトする。ステータスコードは302とか。その他に、ヘッダーにスコープを埋め込むことでトークンの権限範囲を指定する。
- 所有者は認可サーバーでクライアントの権限などを認識した上でクライアントを認可する。
- 認可サーバーは所有者をクライアントへ認可コードと共に送る。これはURIに
code=???として埋め込まれる - クライアントは認可コードと自身の認証情報を認可サーバーに送る。認可サーバーは認可コードが3.で発行されたものであることを検証し、問題がなければトークンを発行する。
- クライアントはトークンを得て、リソースにアクセスする。
なんらかのサービスのAPIを利用しようとした時にBearer Tokenがなんちゃら…と言われると思うが、そのBearer Tokenはこのアクセストークンである。
// ず
もちろんトークンには有効期限があるので、トークンを新たにリクエストするためのリフレッシュトークンというものも存在する。リフレッシュトークンの仕組みは単純であり、
- 認可サーバーにリフレッシュトークンと古いアクセストークンを送る
- 新しいアクセストークンが返送される
という形でアクセストークンを新しくすることができる。
OAuthは認証ではない
要追記
セキュリティ
要追記
実装とか
要追記