本文へスキップ
Hironobu Iga

認可の標準仕様 AuthZEN を調べた

KubeCon + CloudNativeCon Japan 2026 で初めて知った認可の標準仕様 AuthZEN について、解決しようとしている課題、OIDC との関係、現在のステータスを調べて整理しました。

公開日

はじめに

KubeCon + CloudNativeCon Japan 2026 のセッションで、AuthZEN という仕様の名前を初めて聞きました。認可を標準化する仕様だという説明でしたが、その場では全体像がつかめなかったので、OpenID Foundation の仕様と関連のアナウンスを読んで整理しました。

私自身この領域を学び始めたばかりで、本稿は事実の解説というより「調べたらこう理解した」という記録です。理解が違っていたところは、実際に動かして確かめながら直していくつもりです。実装を伴う検証は別の記事にする予定で、本稿は仕様の位置づけと現状の整理までにとどめます。

AuthZEN とは

調べてまず分かったのは、AuthZEN が 1 本の仕様の名前ではなく、OpenID Foundation の AuthZEN Working Group と、そこが策定する仕様群の呼び名だということです。中心になる仕様は Authorization API 1.0 で、アプリケーションが「この利用者はこの操作をしてよいか」を認可エンジンに問い合わせる API を定めています。

この仕様は、認可の判断と適用を分ける構成を前提にしています。判断を担う側がポリシー決定ポイント（PDP: Policy Decision Point）、アプリケーション側で判断を求めて結果を適用する側がポリシー実施ポイント（PEP: Policy Enforcement Point）です。Authorization API が標準化するのは、この PEP と PDP の間の通信だけです。ポリシーの記述言語や PDP の内部実装は対象外で、これは後述するとおり意図的な割り切りのようです。

解決しようとしている課題

認可の判断をアプリケーションのコードから切り出し、専用のエンジンに寄せる構成は、以前から推奨されてきました。if 文の形で各所に埋め込まれた認可ロジックは、権限ルールが変わるたびにアプリ全体の改修になり、いま誰が何にアクセスできるのかを外から監査することも難しくなるためです。OPA（Open Policy Agent）や Cedar のようなポリシーエンジンが使われるのも、この流れの上にあります。

ところが、切り出した先のエンジン（PDP）とアプリケーション（PEP）の間の通信には標準がなく、エンジンごとに独自の API を使う状態が続いていました。アプリが N 個、エンジンが M 個あれば N×M 通りの統合を作ることになりますし、エンジンを乗り換えるときはアプリ側の呼び出しコードをすべて書き直すことになります。

AuthZEN は、この PEP と PDP の間の通信を 1 つの標準 API に揃えようとしています。アプリケーションは Authorization API だけを話せばよく、背後の PDP は差し替えられるようになる、という狙いです。統合の数で言えば、N×M を N+M に減らす試みです。

認可の標準化の試み自体は初めてではなく、2000 年代には XACML1 という OASIS の標準がありました。XACML はアーキテクチャからポリシー言語までを包括的に定めましたが、その複雑さのために普及しなかったと振り返られることが多いようです。AuthZEN が通信だけを標準化し、ポリシー言語には踏み込まないのは、この経緯を踏まえた設計判断だと私は理解しました。なお、PDP や PEP という区分も、この時代のアーキテクチャから受け継がれたものです。

仕様の中身

Authorization API 1.0 は HTTPS 上の JSON という素朴な作りで、判断要求は次の 4 つの要素で表されます。

  • subject：誰が（利用者やワークロードなど、アクセスの主体）
  • action：何をしようとしているか
  • resource：何に対してか
  • context：時刻など、判断に使う環境情報（任意）

たとえば POST /access/v1/evaluation に送る判断要求は次のような形です。

{
  "subject": { "type": "user", "id": "alice@example.com" },
  "action": { "name": "can_read" },
  "resource": { "type": "document", "id": "123" }
}

応答の中心は真偽値 1 つで、判断の理由などの付加情報は任意の context 欄で返す設計です。

{ "decision": true }

エンドポイントは 5 つあります。

  • Access Evaluation：1 件の判断を問い合わせる
  • Access Evaluations：複数の判断を 1 回の呼び出しにまとめて問い合わせる
  • Subject Search / Resource Search / Action Search：可否ではなく、「できる」主体、対象、操作の一覧を問い合わせる

Search 系のエンドポイントは、「アクセスできるリソースだけを一覧に表示する」ような画面を想定したもののようです。可否の判断だけだと一覧表示のたびに全件を問い合わせることになるので、最初からこれが仕様に含まれているのは実用的だと感じました。

OIDC との比較

AuthZEN は「認可における OIDC」と紹介されることがあります。調べる前はこの説明がピンと来ていなかったのですが、それぞれが何を標準化したのかを並べると腑に落ちました。

OIDC（OpenID Connect）が標準化したのは認証、つまり「いま来ているのは誰か」を確かめる部分です。標準化されたことで、任意のアプリケーション（RP）と任意の ID プロバイダ（OP）が組み合わせられるようになり、ログインを自作せず IdP に任せる構成が当たり前になりました。AuthZEN は同じことを認可、つまり「その主体はこの操作をしてよいか」で起こそうとしています。

OIDC AuthZEN（Authorization API）
答える問い いま来ているのは誰か この主体はこの操作をしてよいか
標準化の対象 認証フローと ID トークン 判断要求と応答の API
つなぐもの アプリ（RP）と ID プロバイダ（OP） アプリ（PEP）と認可エンジン（PDP）
判断のタイミング 主にログイン時 リクエストごと

つまり両者は競合ではなく補完の関係で、OIDC で確定させた「誰か」を subject に載せ、AuthZEN で「してよいか」を問い合わせる、という順につながります。どちらも OpenID Foundation の仕様なので、認証と認可が隣り合わせで標準化されていくことになりそうです。

また、「認可」という語からは OAuth 2.0 も連想しましたが、役割は重なっていないようです。OAuth 2.0 のスコープが表すのは「このクライアントにどの範囲の権限を委譲するか」という粗い粒度で、「この利用者がこの伝票を承認してよいか」のようなリクエスト単位の細かい判断はアプリケーションの中に残ります。AuthZEN が扱うのは、この残っていた部分です。

現在のステータス

Authorization API 1.0 は、2026 年 1 月に OpenID Foundation の会員投票で Final Specification として承認されました。2024 年 11 月に Implementer’s Draft になってから 1 年あまりでの確定です。Final Specification は以後改版されない安定版という位置づけで、仕様本文は OpenID Foundation のサイトで公開されています。

策定と並行して相互運用テストが繰り返されてきたのも特徴のようで、ベンダーどうしの接続結果が AuthZEN Interop のサイトに公開されています。対応は認可を専業とする製品やサービスが先行している印象で、より汎用のスタックに目を向けると、Keycloak では対応に向けた議論が始まり、OPA にも対応を求める issue が出ている、という段階に見えました。

仕様が確定した後も動きは続いています。2026 年 6 月には新しいワーキンググループドラフトが 2 本公開されました。1 本は承認や追加の確認が済むまで認可できない場面を扱うプロファイル（Access Request and Approval Profile）、もう 1 本は MCP（Model Context Protocol）のツール呼び出しを AuthZEN の形式で認可するプロファイルです。どちらも AI エージェントの認可を意識した内容で、確定した 1.0 を土台に適用範囲を広げている段階のようです。エージェントに何をどこまで許すかという問題意識は KubeCon + CloudNativeCon Japan 2026 の会場でも繰り返し目にしたので、この領域が入口になって広まっていくのかもしれません。

これから試したいこと

仕様そのものは小さく、まず AuthZEN 対応の PDP を 1 つ立てて Authorization API を叩いてみるのが手頃な入口に見えています。次のあたりから順に検証して、記事にしていく予定です。

  • AuthZEN 対応の PDP を立てて、evaluation エンドポイントの挙動を確かめる
  • Search 系のエンドポイントで「アクセスできるものだけの一覧」を組み立てる
  • OIDC での認証と組み合わせて、認証した主体を判断要求につなぐ

参考リンク

Footnotes

  1. eXtensible Access Control Markup Language。認可のアーキテクチャとポリシー言語を XML ベースで定めた OASIS の標準。最新版の 3.0 は 2013 年に標準化されています。 ↩

続けて読む