PostmanとDropboxを使用してOAuth2.0を理解する

code grant

Dropboxにログインしていると「大丈夫そ？」と聞かれる

双方のブラウザがUserAgent

Applicationからのアクセスを許可するのね。ユーザーを許可すると言うよりは。

アプリケーションIDとシークレットIDは、ユーザーネームとパスワードのようなもの。

この情報をリソースオーナーと共有する。

リダイレクトURIs：Application（Client）が存在している「Webサイト」を持っているかに関わらず、リダイレクトURIsは必要。なぜなら、auth(認証)はHTTP上で行われるから。（auth still works over http）

Inplicit grant：これはまた別のフローらしいからDisallowにする

permissionタブから、許可する権限を選択

A側の設定にAのURLを入れることは多分ないでしょう。入れるとしたら、BのURLを入れてBを許可するみたいになるでしょ。

A側はPostmanになる。
なるほど、アクセスしたいサーバーの情報を全て入れる。Scopeの文字列は、Dropboxで定義している文字列でOK.それ以外はない。

あらかじめDropboxで定義しておいたのと同じRedirectURLsが既に入っている。
だからさっき、Dropboxで定義できたのかあ。
CallbackURLの値は、クライアント側で決められているのね。

AuthURLとAccessTokenURLは、サーバー側で決められてるのでドキュメントを見ればわかる。

どこへ？誰が？どのくらいの権限で？

つまづいたポイント

submitを推してなかったから、許可する権限のscopeが反映されてなかった。

submitを押して、正常に反映されたら成功

postmanからのポップアップになるのね

postman://app/oauth2/callback?~~~~
一風変わったURLなのはなぜか？内部のプロトコル、ブラウザーはそのApp(postmanデスクトップアプリ)を開ければいいと言うのを知っている。

postmanにリダイレクトされてトークンが返ってきた！

整理

一回目の認証では以下が行われる。

まずクライアントAppは、Dropbox認証サーバーへApp IDとApp Secretの検証を申し出る
OKが出たら、次はアクセストークンをリクエストするためのエンドポイントへリダイレクト？？それとも、エンドポイントへのリクエストに１の検証結果も一緒に持っていくのか？
アクセストークンのエンドポイントへアクセスしてトークンをリクエストする
２.の途中、Dropboxのリソースオーナーに対して、Dropboxから、「リクエストしてきたAppに対して、事前に決めておいたサーバーへのscopeを許可するか？Yes or Noで答えてな？」というPOPが来る（もし、ここでDropboxにログインしてなかったらリソースオーナーのユーザー認証を行う）。
DropboxオーナーがYesと答える
あらかじめ設定しておいたCallbackURLにトークンを渡す。（これはHTTP上で行われる通信だからURLとなるが、）
デスクトップアプリを使用しているならば、デスクトップアプリを起動するように（ブラウザの？）内部プロトコルでやってくれるのだ。

2回目以降のアクセスは

Postmanからやったけど、ClientIDとClientSecretが入っているのは、パラメータなのかヘッダーなのかボディなのかがあんまりよくわかってなかった。

Postmanって、一方的に投げるだけなのかと思ってたけど、OAuth2.0みたいに複雑な双方向の通信もできるんだなと思った。Postman専用のCallbackURLが用意されていたことに驚き。」

学んだこと

「Postmanささっと使いこなすって、かっこいいな。」