スマホネイティブアプリではCookieを使ったセッション管理は出来るんだっけ？出来ないんだっけ？の話

要件

要件として

こんなアプリケーションを作る場合、セッション管理ってどうやるのがいいのか。

Webブラウザでは一度認証したあとのログイン状態の保持にはCookieを使ったセッション管理でするのが一般的。

サーバ側はRedisのようなKVSを用意してセッションIDとユーザIDを管理し、一定期間が過ぎると削除する。

みたいな実装。これでセッションを管理出来る。といった感じ。

ではスマホネイティブアプリではどうなのか。

ネイティブアプリではユーザビリティ向上のためログイン状態を出来るだけ保持しつづける必要がある事が多い。

確かによく使うスマホアプリの挙動を思い出してみてもそうなっている。

そしてそもそそもの問題としてCookieはブラウザの概念なのでスマホネイティブアプリは使うことは出来ない。

そうなんだ！でもCookie使えなくてもセッションIDをなんらかのセキュアな場所で保存しておけばいいのでは？

と思ったが、まるっとそう収まらない。

それはCookie自体がある程度セキュリティ面での取り扱いも仕様上制限されてる上での前提があってセキュアに使われてるだけであって、「じゃあ代わりのストレージでセッションIDを保持しよう！」となることは一般的ではない。

つまり、やろうと思えばブラウザのように

「サーバ側にセッション情報を保持し、クライアントはなんらかのストレージでセッションIDを保持する」

のような実装も出来ることはできる。でもやらない。

スマホネイティブアプリは一般的には「トークンベースの認証」を採用するパターンが多い。

「Cookie使えないからプラットフォーム毎に異なるかもしれないけどいい場所でセッションIDを保持するね！」としてもセキュリティ的にも不安で、セッション管理が複雑になる。

それだったらステートフルなトークンベースの認証を採用しようね、って流れは理解できそう。

認証が違うので当初想定していた

「プラットフォーム毎にセッション期限を柔軟に変えたいな・・・」という問題も手っ取り早く対応できそう。

めでたしめでたし（？）

最初の話に戻る。

要件として

とした場合。まずログイン用の受け口を2つ作る。

ブラウザからは

スマホからは

初回ログイン時に秘密鍵で暗号化したアクセストークン&シークレットトークン(JWT)を払い出す。
クライアント側で両方のトークンを保持してサーバ側ではシークレットトークンをRDBで保持する。
セキュリティのため有効期限を短く設定してあるアクセストークンをリクエスト毎に投げる。
有効期限が切れた場合にリフレッシュトークンをサーバ側に送信する。検証が成功すればリフレッシュトークンとアクセストークンを再生成してアクセストークンをクライアント側に払い出して再度アクセスを行う。
リフレッシュトークンで設定した期限が来るまでセッションは維持される

的なことをやれば要件を満たすユーザ体験を提供できた。