https://blog.yusukeikoma.com/tags/security/Recent content in security 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/websocket-origin-check-is-not-authentication/Thu, 10 Sep 2026 11:23:25 +0900https://blog.yusukeikoma.com/posts/websocket-origin-check-is-not-authentication/The Origin header on a WebSocket handshake is set by browsers and can be set to anything by every other client. So an allow-list protects a cookie-authenticated browser session from other sites, and it proves nothing about who is connecting. A runnable server, a real headless-browser attack, and the handshake rule that follows.https://blog.yusukeikoma.com/posts/websocket-reauthentication-on-long-lived-connections/Fri, 21 Aug 2026 13:34:18 +0900https://blog.yusukeikoma.com/posts/websocket-reauthentication-on-long-lived-connections/After the 101 response, no request carries credentials: the server remembers a verdict, not the evidence. This article follows one token through a browser handshake, shows what a page can and cannot see, and compares three ways to renew it (reconnect, in-band, out-of-band) with a runnable server, tests, and a headless-Chrome check.https://blog.yusukeikoma.com/posts/separate-authentication-and-authorization/Tue, 11 Aug 2026 17:14:04 +0900https://blog.yusukeikoma.com/posts/separate-authentication-and-authorization/Designing API authentication and role-based authorization with actors, route permissions, and separate credentials for people and machines.