APIトークン認証の論理設計

SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう

[BOOOOOOOON]

認証は自前で実装するのやめよう

[maninthemiddle]

トークン取得方法ほOAuth+OIDCでトークンはJWT、リフレッシュトークンはDB管理、が一番よく見かけるパターンのように思う

[Kil]

最適解は、「1番メジャーな外部サービスに全乗っかり」でしょ。仮になにか新たな問題が生まれても、1番早く解決策が提示されるしね。

[prograti]

リトライで良い気がするけどシステム要件的にNGだったのかな？ "一方のリクエストによりアクセストークンが書き換わり、他方のリクエストが弾かれるという問題にしばしば直面します"

[ya--mada]

ララベル使いの人の悩みってることらしい…

[Magicant]

「気持ちが悪い」ってだけで何か解決しなきゃならない問題があると思ひ込んでしまふやうな人はシステム設計に向いてないんでは

[NOV1975]

フロントエンドの実装が面倒になるのは標準から外れたものを作るからであってOIDCでも使えばってなるだけ

[hiroharu8864]

あとで

[hasiduki]

トークンのリフレッシュってiframeでそれ用のエンドポイント叩くだけでは？？？？？？

[Shinwiki]

「書く」ことで自己解決してしまうパターンでは。ざっと読んだけどもう答え持ってそう