はじめに
OAuth2ってなにそれおいしいの？から、「完全に理解した」（つまり、なんとなくわかる程度）になるための手助けのひとつとなるのは、やっぱり使ってみること。
そんなときちょうどいい題材としてfitbitを使ってみましょう、ということでさっと使うところまで。なので、OAuth2についての詳しい解説はほかにさんざん良い記事やrfcの解説がありますので、ここでは行いません。
またあくまで使う側（クライアント側）としての内容なので、認可サーバーやリソースオーナー側については言及しません。
なぜfitbit？（だって資料が豊富だから）
なんだかんだで、公式ドキュメント。
あとはサンプルコード1があるので、大抵の内容はこのあたりでカバーできます。
またOAuth2.0のチュートリアルなんてページまで用意してくれています。
データの取得については、公式が用意してくれているSwagger(OpenAPI)ですべて試せます。
ここでどんなjsonが落ちてくるか眺めながらなにを使うか考えていきます。
このあたりまでで目的が達成できる方は、以下を読む必要ありません。
準備
ここから下が、この記事の本題です。
まず登場人物は、ここで定義される、リソースオーナー、リソースサーバー、クライアント、認可サーバーです。
fitbitのデータを持っているエンドユーザ（つまりあなた）は、リソースオーナーです。
fitbitのサーバーは、データを管理するリソースサーバーと、データへのアクセスを許可する認可サーバーの役割を果たします。
クライアントは、リソースオーナーの許可を得てリソースにリクエストするアプリケーションです。
事前準備として、Register an applicationから、データを取得するアプリケーションを追加、つまりクライアントを登録して、一意となるCLIENT_IDを発行しておく必要があります。
データに対するアクセス許可
ここの操作は、すべてクライアントがリソースにアクセスするための手続きです。
よく使われている（んじゃないかと思う）Pythonのサンプルをベースに、なにをやっているかを説明します。
1. 認可サーバーへのリクエスト発行
クライアント識別子を使って一意に指定されるクライアントは、authorize_token_urlメソッドを使用して、認可サーバーの/oauth2/authorizeに対してリクエストを発行します。
# サンプル
https://www.fitbit.com/oauth2/authorize?client_id=ABC123&response_type=code
&scope=weight%20location%20settings%20profile%20nutrition%20activity%20sleep
%20heartrate%20social
未ログインの場合はログインを挟んで、認可サーバーではリソースオーナーがクライアントにアクセス許可を与えるページに遷移します。
2. 認可サーバーからクライアントへのリダイレクト
画面で許可操作を行うと、クライアントのアプリケーションが用意している画面にリダイレクトされます。リダイレクト先は、authorizeのパラメータとしての送るredirect_urlと、準備で登録したurlが一致している必要があります。
リダイレクトをうけとったクライアントは、リダイレクトURLに含まれる認可コードを使用してトークンをリクエストします。
3. アクセストークンのリフレッシュ
アクセストークンは有効期限が定められているので、定期的にリフレッシュトークンを利用して、再発行が必要です。
{
"access_token": "<access_token>",
"expires_in": 28800,
"refresh_token": "<refresh_token>",
"scope": "social settings heartrate nutrition sleep activity profile location weight",
"token_type": "Bearer",
"user_id": "<user_id>"
}
おわりに
なお実はPythonのサンプルの中ではPKCEを使用していません。セキュリティを強化するためには、PKCEに対応した処理を追加することが望ましいかと思います。