<?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/ja/tags/authorization/</link><description>Recent content in authorization on Ikoma's Blog</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Thu, 17 Sep 2026 09:49:13 +0900</lastBuildDate><atom:link href="https://blog.yusukeikoma.com/ja/tags/authorization/index.xml" rel="self" type="application/rss+xml"/><item><title>古い JWT 検証側は新しい制限クレームを無視するので、制限は scope を絞って表す</title><link>https://blog.yusukeikoma.com/ja/posts/ignoring-unknown-jwt-claims-only-removes-access/</link><pubDate>Thu, 17 Sep 2026 09:49:13 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/ignoring-unknown-jwt-claims-only-removes-access/</guid><description>JWT の仕様は、検証側が理解できないクレームは無視するよう定めています。権限を与えるクレームなら無害ですが、制限するクレームでは危険です。クライアントの種類ごとに持てる権限の上限を決める4つの設計を、小さな発行者と3種類の検証側で試し、僕が選ぶ設計を示します。</description></item><item><title>認証としてよいことを分ける</title><link>https://blog.yusukeikoma.com/ja/posts/separate-authentication-and-authorization/</link><pubDate>Tue, 11 Aug 2026 17:14:04 +0900</pubDate><guid>https://blog.yusukeikoma.com/ja/posts/separate-authentication-and-authorization/</guid><description>API の認証とロールベース認可を、主体・経路ごとの権限・人とマシンの認証情報に分けて設計する方法を説明します。</description></item></channel></rss>