<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>authorization on Ikoma's Blog</title><link>https://blog.yusukeikoma.com/tags/authorization/</link><description>Recent content in authorization on Ikoma's Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Thu, 17 Sep 2026 09:49:13 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/tags/authorization/index.xml" rel="self" type="application/rss+xml"/><item><title>Old JWT Verifiers Ignore a New Restricting Claim, So Restrict by Narrowing scope</title><link>https://blog.yusukeikoma.com/posts/ignoring-unknown-jwt-claims-only-removes-access/</link><pubDate>Thu, 17 Sep 2026 09:49:13 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/ignoring-unknown-jwt-claims-only-removes-access/</guid><description>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.</description></item><item><title>Separate Authentication from What an Actor May Do</title><link>https://blog.yusukeikoma.com/posts/separate-authentication-and-authorization/</link><pubDate>Tue, 11 Aug 2026 17:14:04 +0900</pubDate><guid>https://blog.yusukeikoma.com/posts/separate-authentication-and-authorization/</guid><description>Designing API authentication and role-based authorization with actors, route permissions, and separate credentials for people and machines.</description></item></channel></rss>