適当にだらだら書く。
クライアントマシン と サーバーマシン があるとする。
クライアントマシンとして やることは、
- ログイン
- APIの利用
- 認証の期限の延長
の３つがある。
ユーザー認証しよう
OAuth2 の仕組みでは、だいたい２つの URL を教えられていると思う。
/authentication/token
とか。つづりは違うかもしれない。この２つは何なのか。それは
- ログイン
- トークンの発行
の違いだぜ。
ログインとは
- ユーザー名
- パスワード
を入力する画面のことだぜ。これが /authentication ページの仕事だぜ。
ログインに成功すると、 /token ページに飛ばされると思う。
/token ページって何なのか？
サーバーが、
- アクセストークン
- リフレッシュトークン
の２つをクライアントマシンに送るページだぜ。トークンとは、単なる長い文字列なので、クライアントマシンのファイルに２つとも保存しておけだぜ。
クライアントマシンから サーバーマシンに アクセスして APIを叩こうとするたびに、アクセストークンが必要になる。
クライアントマシンに保存してあるファイルから アクセストークンを読み込んで使えばいいだろう。
このアクセストークンには有効期限があって、例えば １時間で 有効期限が切れてしまったりする。
じゃあ、有効期限を延ばすにはどうすればいいのか。それは サーバーから
- 新しいアクセストークン
- 新しいリフレッシュトークン
のペアを再送してもらうことだぜ。どうやったらできるのか？
/token ページに向けて、アクセストークンと リフレッシュトークン を送信しろだぜ。
どっちも クライアントマシンのファイルに保存してあるだろ。読み込めだぜ。
すると、
/token ページは 新しいアクセストークンと 新しいリフレッシュトークンを送り返してくる。
クライアントマシンのファイルに 両方とも保存しろだぜ。
つまり、
ログインしなおしたのと 同じ流れ に乗れるので、プログラムの追加は無いはずだぜ。
１回使ったリフレッシュトークンや、新しいアクセストークンを発行したあとの古いアクセストークンは使えなくなるので、
捨ててしまえだぜ。
だから
- アクセストークン
- リフレッシュトークン
を保存するファイルも１個でいい。上書き保存で行ける。
理屈としては、アクセストークンは毎回必要だから 盗聴されやすい。だから１時間で有効期限を切る。
リフレッシュトークンは ログイン時と、トークンの更新時の２回しか 通信上で流れないので 盗聴されるリスクが軽減、
というだけだぜ。
で、リフレッシュトークンを送信するタイミングだが、アクセストークンの有効期限が切れたあとでもいいし、
切れる５分前に送ってもいいし、さっさと 送ってもいい。
ただし １分毎に送っているようでは 通信上に余り流れないというメリットがなくなるので そんなことはしない。