https://blog.yusukeikoma.com/ja/tags/oauth/Recent content in oauth on Ikoma's BlogHugoja-jpThu, 17 Sep 2026 09:49:13 +0900https://blog.yusukeikoma.com/ja/posts/ignoring-unknown-jwt-claims-only-removes-access/Thu, 17 Sep 2026 09:49:13 +0900https://blog.yusukeikoma.com/ja/posts/ignoring-unknown-jwt-claims-only-removes-access/JWT の仕様は、検証側が理解できないクレームは無視するよう定めています。権限を与えるクレームなら無害ですが、制限するクレームでは危険です。クライアントの種類ごとに持てる権限の上限を決める4つの設計を、小さな発行者と3種類の検証側で試し、僕が選ぶ設計を示します。https://blog.yusukeikoma.com/ja/posts/step-up-authentication-challenge-is-a-401/Tue, 15 Sep 2026 13:18:09 +0900https://blog.yusukeikoma.com/ja/posts/step-up-authentication-challenge-is-a-401/RFC 9470 は、API がクライアントに「このトークンは、弱すぎる、または古すぎるログインで取得されたものだ」と伝える方法を定めています。RFC を節ごとに読み、試作のサーバーとクライアントを作ると、仕様が決めているもの(401 のチャレンジと2つのパラメーター)と、実装側に残されているもの(同時に届くチャレンジ、ループ、キャッシュ)が分かります。https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/Sun, 30 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/ja/posts/refresh-token-rotation-concurrent-requests/リフレッシュトークンのローテーションは、使用済みトークンの再利用を盗難の警報として扱います。期限切れのアクセストークンで3つのリクエストを同時に送り、401ごとに更新するクライアントは、同じリフレッシュトークンを3回提示して、自分で警報を鳴らします。この記事では、素朴なクライアントをあえて壊し、single-flight と stale check で直します。そのうえで、サーバー側の猶予期間、リクエストの待機、先回り更新、送信者制約付きトークンを比べます。