https://blog.yusukeikoma.com/tags/oauth/Recent content in oauth on Ikoma's BlogHugoen-usThu, 17 Sep 2026 09:49:13 +0900https://blog.yusukeikoma.com/posts/ignoring-unknown-jwt-claims-only-removes-access/Thu, 17 Sep 2026 09:49:13 +0900https://blog.yusukeikoma.com/posts/ignoring-unknown-jwt-claims-only-removes-access/The JWT specification tells verifiers to ignore claims they do not understand. That is harmless for claims that grant things and dangerous for claims that restrict them. Four ways to cap what a client kind may hold, tested with a small issuer and three verifiers, and the one I would pick.https://blog.yusukeikoma.com/posts/step-up-authentication-challenge-is-a-401/Tue, 15 Sep 2026 13:18:09 +0900https://blog.yusukeikoma.com/posts/step-up-authentication-challenge-is-a-401/RFC 9470 lets an API tell a client that its access token was obtained with too weak or too old a login. Reading the RFC section by section, then building a toy server and client, shows what the document specifies (a 401 challenge, two parameters) and the three things it leaves to you: concurrent challenges, loops, and caches.https://blog.yusukeikoma.com/posts/refresh-token-rotation-concurrent-requests/Sun, 30 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/posts/refresh-token-rotation-concurrent-requests/Refresh token rotation turns a reused token into a theft alarm. A client that fires three requests with an expired access token and refreshes once per 401 presents the same refresh token three times, and trips that alarm on itself. This post breaks a naive client on purpose, fixes it with single-flight refresh and a stale check, and compares the alternatives: a server grace window, request gating, proactive refresh and sender-constrained tokens.