JWTでユーザー認証する

[syuilo]

Summary

JWTでユーザー認証する

Purpose

• 実装がシンプルになり、場合によってはバックエンドでユーザー情報を別途取得しないでも良くなることからパフォーマンス向上しそう
  • localUserByNativeTokenCache が要らなくなることからメモリ使用量が減る
• Signout should invalidate session server-side | サインアウト後にtoken自身も無効にして欲しい #15567 などに対応できそう

Do you want to implement this feature yourself?

• Yes, I will implement this by myself and send a pull request

[kakkokari-gtyih]

場合によってはユーザー情報を別途取得しないでも良くなる

多分全情報をJWTに乗せるのは悪手

[syuilo]

全情報は載せない

[syuilo]

ホームタイムライン取得するAPIを考えると、必要なのはユーザーIDくらいで、ユーザー名とかは明らかに不要

[kakkokari-gtyih]

あーサーバー側でってことか

[kakkokari-gtyih]

#15567 などに対応できそう

マスターのログイントークンをJWTに入れて iat を付与したものを通常のログイントークンとする → ログイン処理ごとにどこかにJWTを格納する → ログアウト時にJWTを削除する
ペイロードにユーザーIDなどの変更不可能なものを含めるかたちでJWTを発行する場合にJWTを取り消す手段がないということでJWTは悪手と言われるが、ログイントークンをJWTのペイロードに入れるようにすることで、今まで通りログイントークンの再生成を行えば今までのログイントークンを含んだJWTも無効にすることができるはず

[syuilo]

#15567 などに対応できそう

マスターのログイントークンをJWTに入れて iat を付与したものを通常のログイントークンとする → ログイン処理ごとにどこかにJWTを格納する → ログアウト時にJWTを削除する ペイロードにユーザーIDなどの変更不可能なものを含めるかたちでJWTを発行する場合にJWTを取り消す手段がないということでJWTは悪手と言われるが、ログイントークンをJWTのペイロードに入れるようにすることで、今まで通りログイントークンの再生成を行えば今までのログイントークンを含んだJWTも無効にすることができるはず

これだとパフォーマンス向上のメリットは消えそう？

[syuilo]

JWTの有効期限を数分といった短い期間にする & ステートレス
にすれば今より安全性もパフォーマンスもどっちも向上できそうに思った

[syuilo]

現実的には定期的にリフレッシュが必要ということを考えるとリフレッシュトークン<->ユーザーのキャッシュは持っておく必要があり、結局はパフォーマンス向上にはつながらなさそう

[syuilo]

いやリフレッシュの頻度によっては別にキャッシュ無くても良いか

[syuilo]

あと署名の生成・検証でどれくらいCPUを消費するのかは気になる

[KisaragiEffective]

HMAC-SHA512 (HS512) であれば比較的重くなさそう
確実に言えるのはAPの署名よりは軽いこと

[eternal-flame-AD]

I can take on this issue next week if no one is already working on an implementation, I wanted this for my own instance too.

[kakkokari-gtyih]

I can take on this issue next week if no one is already working on an implementation, I wanted this for my own instance too.

Schedule is not fixed yet, but we might do the overhaul of the login auth by @acid-chicken (#13865) so maybe we should coordinate who and when to actually implement

[eternal-flame-AD]

I think transition to JWT (or any alternative format than random string we agree on) should be done first, because many features in #13865 are contingent upon a rich token format (tokens with structured info that backend can parse).

パスワード認証を要求するすべてのエンドポイントを sudo トークンに置き換える -> this is essentially granular token policy

sudo モード -> this needs ways to identify tokens too (like a token_sudo_until table), and we have to agree on a format first before all

SSO -> many SSO services require you to store refresh tokens, so we need a rich format too

[eternal-flame-AD]

I propose we do this, we don't have to have me or anyone dictate how it works, we can do a few stages

• spec out how the token is formatted, authenticated, and optionally encrypt secret state
• discuss with @acid-chicken about their opinion on frontend adoption

On second around we implement in this order again.