ハッカーニュースでJWTやOAuthに関する記事を探すと、何百ものコメントが循環論争をしてるのが見つかるよ。人々はこの二つを分けるのがなかなかできないみたい。

一般的に、クッキーはドメイン間で再利用できないんだ。ブラウザがどのドメインにどのクッキーを送るかを制御してるからね。それに、クッキーは暗号的に署名されてないから、クライアントやブラウザによって簡単に偽造されちゃう。一方、JWTはドメインを越えて使えるから、あるドメインで発行されたIDPのJWTを別のドメインでも信頼できるんだ。暗号署名はデータの整合性を確認するのに役立つし、セッションは通常、一つのバックエンドやアプリケーションサーバーに結びついてるから、異なるアプリ間でセッションデータを再利用するのは難しい。でもJWTは異なるアプリサーバーやマイクロサービス間でセッションデータを共有できるんだよ。

クッキーはサーバーによってのみ制御されるけど、当然秘密を使って交渉することもできる。JWTは相互秘密のコンポーネントが組み込まれてて、かなりクールな感じだよね。だから、両方のエンドが相手を信頼して、JWTで証明する必要がある。クッキーが絡むと、運を天に任せることになるけど、相互TLSを使えばJWTが提供するのと同じ信頼を得られるよ。私が運用してるウェブアプリは両方使ってるんだけど、ウェブ開発者たちはJWTを主張して、ああ、認証ベアラーの部分を「忘れちゃった」みたいで、彼らのAPIでは使ってなかったんだ。結局、Apacheモジュールを修正して再コンパイルする羽目になったけど、次のバージョンでサポートするって言ってたから、私の変更を戻せるかも。今使ってるApacheプロキシのJWTモジュールでDBをちょっと調べれば、クレームが得られるよ。その前には、PrivacyIDEAインスタンスに対して認証が成功したときに生成されるApacheセッションクッキーがある。つまり、認証にはクッキー、認可にはJWTを使ってる感じかな。クッキーは両方できるけど、セッション以外はあまり詳しくないから、クレームを複数のクッキーで扱う必要があるように見えるけど、JWTは一つで全部できるんだよね。

そうそう、トークンはすぐに長くなるよね。5年前にクライアントに役割を渡すために使おうとしたこともあったけど、いろいろ問題が出たんだよね。

認可は本当に一般的に解決可能な問題じゃないんだ。大きなシステムはそれぞれ独自のクセがあるし、一般化しようとすると痛みや苦しみ、そしてAWS IAMに繋がるんだよね。

Biscuitをチェックしてみるといいかもね。 > Biscuitは、分散型検証、オフラインの軽減、論理言語に基づく強力なセキュリティポリシー強制を持つ認可トークンだよ。 — https://www.biscuitsec.org

一度、JWTに権限を付与しようとしたことがあるけど（君の人気のスコープよりも複雑）、それだとすぐに大きくなっちゃう。ビットマスクを使うことで解決したよ。例えば、「カレンダーオブジェクトからの読み取りを許可する」というアクセスルールをエンコードしたいとする。典型的なCRUDアクションは4ビットでエンコードできる。例えば、すべてのビットがゼロなら→アクセスなし。最初のビットが1なら→作成可能。2番目のビットが1なら→読み取り可能。などなど。で、もしシステムに32種類のオブジェクトがあれば、「位置13はカレンダーをエンコードする」と言える。だから、32×4＝128ビット、つまり32種類のオブジェクトに関するCRUDルールの情報をエンコードするのにたった16バイトで済む。確かに複雑に聞こえるけど、ライブラリに移せば考えなくて済むよ。

内容は驚くべきものではなく、私のフルネームとメールアドレスだよ。正しく記憶しているか分からないけど、これに関してはJWTに識別情報を保存しないことが推奨されているんじゃなかったっけ？