用語集

本書で定義した技術用語を分野別にまとめました。括弧内は英語表記、末尾のリンクは初出の章です。各分野の中は初出の章の順に並べています。

HTTPとWebの基礎

TCP(Transmission Control Protocol): HTTP/1.1 と HTTP/2 が下位で使う、順序と到達を保証するバイト列の通信の取り決め。1章
HTTP/2/HTTP/3: HTTP の新しい版。メッセージの送り方(バイナリのフレーム、QUIC の利用)が異なるが、ヘッダとステータスコードの意味は HTTP/1.1 と同じ。1章
Unicode: 世界の文字に番号(符号位置)を割り当てた文字集合。1章
UTF-8: Unicode の文字を1〜4バイトの列で表す文字符号化方式。ASCII の文字は1バイトのまま表せる。1章
NFC(Unicode Normalization Form C): 同じ見た目の文字の異なる表現(合成済み文字と結合文字の並び)を、合成済みの形にそろえる Unicode の正規化形式。1章
認証(authentication): 通信相手が名乗っているとおりの者であることを確かめる処理。1章
HTTP(Hypertext Transfer Protocol): Webのブラウザとサーバがリクエストとレスポンスをやり取りするためのプロトコル。意味論はRFC 9110が定める。1章
リクエスト行(request line): HTTP/1.1のリクエストの1行目。メソッド、対象のパス、HTTPのバージョンを並べる。1章
ヘッダ(header field): HTTPメッセージに付ける名前: 値の形の付加情報。1章
ステータスコード(status code): HTTPレスポンスの1行目に入る3桁の数で、リクエストの処理結果を表す。1章
Hostヘッダ(Host header field): リクエストの宛先のホスト名を示すヘッダ。1章
Acceptヘッダ(Accept header field): クライアントが受け付けるレスポンスのボディの形式を示すヘッダ。1章
Content-Typeヘッダ(Content-Type header field): メッセージのボディの形式(メディアタイプ)を示すヘッダ。1章
ステートレス(stateless): 各リクエストの意味がそのリクエストだけで決まり、前のリクエストに依存しない性質。HTTPはステートレスなプロトコルである。1章
ステートフル(stateful): サーバ側が利用者ごとの状態(セッションなど)を保持し、リクエストのたびに参照する方式。1章
チャレンジ・レスポンス(challenge-response): サーバがチャレンジで認証方式を示し、クライアントが資格情報を付けて応じる、HTTPの認証の枠組み。1章
チャレンジ(challenge): サーバがWWW-Authenticateヘッダで返す、認証スキームとその引数の組。1章
資格情報(credentials): 本人であることを示すために提示する値の総称。パスワード、トークンなど。1章
認証スキーム(authentication scheme): HTTPの認証方式の名前。Basic、Bearerなど。大文字小文字を区別せずに照合する。1章
realm: サーバ上の保護された範囲を識別する、チャレンジの引数。1章
WWW-Authenticateヘッダ(WWW-Authenticate header field): サーバが受け付ける認証スキームと引数(チャレンジ)を伝えるレスポンスヘッダ。401のレスポンスには必須。1章
Authorizationヘッダ(Authorization header field): クライアントが資格情報をスキーム名資格情報の形でサーバに提示するリクエストヘッダ。1章
Basic認証(Basic authentication): ユーザー名:パスワードをBase64で符号化してAuthorizationヘッダで毎回送る認証方式。RFC 7617が定める。1章
Base64: 任意のバイト列を英数字と+、/の64文字(と長さ調整の=)で表す符号化。暗号化ではない。1章
TLS(Transport Layer Security): 通信路を暗号化し、接続先のサーバを証明書で確認するプロトコル。1章
HTTPS: TLSの上でHTTPを使う方式。URLのスキームはhttps。1章
401 Unauthorized: リクエストに有効な資格情報がないことを表すステータスコード。WWW-Authenticateヘッダを必ず付ける。1章
403 Forbidden: サーバがリクエストを理解したうえで実行を拒否したことを表すステータスコード。資格情報はあるが権限が足りない場合に使う。1章
303 See Other: 別のURLをGETで開き直すよう指示するステータスコード。フォームの送信後によく使う。1章
Locationヘッダ(Location header field): リダイレクトの行き先のURLを示すレスポンスヘッダ。1章
セッション(session): ログインからログアウトまでの一連のやり取りを1つにまとめて扱うための、サーバ側の記録。1章
セッションID(session ID): サーバがセッションを識別するために発行する推測できない値。Cookieでブラウザに保存させる。1章
Cookie: サーバがブラウザに保存させ、以後の同じサーバへのリクエストで送り返させる名前と値の組。RFC 6265が定める。1章
Set-Cookieヘッダ(Set-Cookie header field): サーバがブラウザにCookieを保存させるためのレスポンスヘッダ。1章
Cookieヘッダ(Cookie header field): ブラウザが保存したCookieをサーバに送るリクエストヘッダ。1章
属性(attribute): Set-Cookieヘッダで値の後ろに;で並べる指定。Cookieをいつ送り、誰に見せるかを制御する。1章
Secure属性(Secure attribute): Cookieを、TLSなどの安全な経路のリクエストにだけ付けるよう指示する属性。1章
HttpOnly属性(HttpOnly attribute): Cookieを、スクリプトからCookieを読むAPIに見せないよう指示する属性。1章
SameSite属性(SameSite attribute): 他のサイトを起点とするリクエストにCookieを付けるかどうかをStrict、Lax、Noneで指示する属性。RFC 6265の改訂版(rfc6265bis)が定める。1章
400 Bad Request: リクエストの形式や内容に誤りがあることを表すステータスコード。OAuth のトークンエンドポイントは多くのエラーをこのコードで返す。3章
500 Internal Server Error: サーバ内部の予期しない障害でリクエストを処理できなかったことを表すステータスコード。3章
302(Found): リソースが一時的に別のURLにあることを示すステータスコード。ブラウザはLocationヘッダのURLを自動で開く。3章
リダイレクト(redirect): レスポンスでブラウザに別のURLを開かせること。3章
クエリ文字列(query string): URLの?より後ろの部分。名前=値の組を&で区切って並べる。3章
URLエンコード(URL encoding): URLで特別な意味を持つ文字や使えない文字を、%とバイト値の16進数2桁に置き換える変換。3章
パーセントエンコーディング(percent-encoding): RFC 3986でのURLエンコードの呼び名。3章
application/x-www-form-urlencoded: 名前=値の組を&で連結し、名前と値をURLエンコードする形式。空白は+で表す。OAuth 2.0のクエリとトークンリクエストのボディで使う。3章
JSON(JavaScript Object Notation): オブジェクト、配列、文字列、数値、真偽値、nullを組み合わせてデータを表すテキスト形式。RFC 8259が定める。4章
Cache-Controlヘッダ(Cache-Control header field): レスポンスをキャッシュに保存してよいかを指示するヘッダ。トークンを含むレスポンスにはno-storeを付ける。4章
Pragmaヘッダ(Pragma header field): HTTP/1.0時代のキャッシュ制御のヘッダ。RFC 6749は互換性のためPragma: no-cacheも求める。現在のHTTPの仕様では廃止扱い。4章
serde: Rustのデータ構造とJSONなどのデータ形式を相互に変換するためのクレート。4章
well-known URI(well-known URI): /.well-known/ で始まる、サイト全体に関する情報を置くために予約されたパス。RFC 8615(旧 RFC 5785)が定める。10章
WebFinger: ユーザーの識別子(メールアドレスの形の値など)から、そのユーザーに関する情報の所在を問い合わせる仕組み。RFC 7033 が定め、Discovery の issuer の発見に使う。10章
axum: Rust の Web フレームワーク。URL のパスとハンドラを対応づけ、エクストラクタでリクエストから値を取り出す。tokio の上で動く。11章
tokio: Rust の非同期ランタイム。axum や reqwest の非同期処理を実行する。11章
tower-sessions: axum のハンドラにセッションを提供するミドルウェアのクレート。セッションIDを Cookie で送受信し、中身はサーバ側のストアに置く。11章
ハンドラ(handler): Web フレームワークで、特定のパスとメソッドのリクエストを処理する関数。11章
エクストラクタ(extractor): axum で、リクエストのクエリ、ボディ、ヘッダ、セッションなどを型付きの値として取り出す仕組み。11章
ミドルウェア(middleware): ハンドラの前後に共通の処理(セッションの読み書きなど)を差し込む部品。11章
HTTP クライアント(HTTP client): サーバに HTTP リクエストを送って応答を受け取るライブラリ。本書では reqwest を使う。11章
reqwest: Rust の HTTP クライアントのクレート。本書では OP、リソースサーバとの通信と flow-test に使う。11章
フラグメント(fragment): URIの#より後ろの部分。ブラウザはHTTPリクエストに含めてサーバへ送らず、ページのJavaScriptだけが読める。リダイレクト先のLocationにフラグメントがなければ元のフラグメントが引き継がれる。19章
308 Permanent Redirect: メソッドと本文を保ったまま恒久的に別の URL へ転送させるステータスコード。307 と同じく、POST の本文がリダイレクト先に再送される。22章
Referer ヘッダ(Referer header): ブラウザがリクエストに付ける、遷移元のページの URI を示す HTTP ヘッダ。フラグメントと userinfo は含めないが、クエリ文字列は含まれうる。名前は referrer の誤記が標準になったもの。22章
Referrer-Policy(リファラーポリシー): 文書から出るリクエストに Referer をどこまで付けるかを指定するヘッダまたは meta 要素。no-referrer は Referer を一切送らない。22章
307 リダイレクト(307 Temporary Redirect): リダイレクト先へ同じメソッドと本文でリクエストを送り直させるステータスコード。資格情報を含む POST に使うと本文が転送先に渡る。22章
X-Frame-Options(X-Frame-Options): ページを他のページの frame・iframe に表示してよいかを DENY か SAMEORIGIN で指定するレスポンスヘッダ。22章
frame-ancestors(frame-ancestors directive): ページを埋め込んでよい親ページのオリジンを列挙する CSP のディレクティブ。クリックジャッキング対策に使う。22章
max-age ディレクティブ(max-age directive): Cache-Control ヘッダで、レスポンスを再取得せずに使ってよい秒数を示す指示。RFC 9111 で定義される。JWKS のキャッシュ期間を伝えるのに使う。26章
CDN(content delivery network): 利用者に近い多数の拠点にレスポンスの複製を置いて配信するサービス。レスポンスをキャッシュするため、JWKS の更新が遅れて届く原因になりうる。26章
リバースプロキシ(reverse proxy): サーバの前段でリクエストを受けて中継するサーバ。レスポンスをキャッシュすることがある。26章
429 Too Many Requests: レート制限を超えたリクエストに返す HTTP ステータスコード。RFC 6585 で定義される。26章
Retry-After ヘッダ(Retry-After header): クライアントが次のリクエストまで待つべき時間を示すレスポンスヘッダ。RFC 9110 10.2.3節で定義される。26章

OAuth 2.0の基本

認可(authorization): ある主体が特定の資源に対して特定の操作を行うことを許可する、またはその可否を判定する処理。2章
トークン(token): 何らかの権限や資格を表すために発行される文字列の総称。2章
委譲(delegation): 自分が持つ権限の一部を、範囲を限定して別の者に与えること。2章
OAuth 2.0: 委譲の結果をアクセストークンとして発行する手順を標準化した認可の枠組み。RFC 6749が定める。2章
アクセストークン(access token): 特定のクライアントに、特定の範囲の資源へのアクセスを一定期間許可したことを表す文字列。2章
ロール(role): OAuth 2.0で委譲に関わる者の役割。リソースオーナー、クライアント、認可サーバ、リソースサーバの4つ。2章
リソースオーナー(resource owner): 保護されたリソースへのアクセスを許可できる者。人である場合が多い。2章
クライアント(client): リソースオーナーの許可を得て、その代わりに保護されたリソースへアクセスするアプリケーション。実装の形態は問わない。2章
認可サーバ(authorization server): リソースオーナーを認証して許可を得たうえで、クライアントにアクセストークンを発行するサーバ。2章
リソースサーバ(resource server): 保護されたリソースを持ち、アクセストークンを受け取ってリクエストに応えるサーバ。2章
保護されたリソース(protected resource): アクセスに認可が必要な資源。2章
ユーザーエージェント(user agent): 利用者の代わりにHTTPのリクエストを送るソフトウェア。多くの場合Webブラウザ。2章
権限付与(authorization grant): リソースオーナーがアクセスを許可したことを表す資格情報。クライアントがアクセストークンと交換する。認可コードなど4種類が定められている。2章
フロントチャネル(front channel): ブラウザのリダイレクトを経由する通信の経路。利用者の操作に使えるが、値が履歴やログに残りやすい。2章
バックチャネル(back channel): ブラウザを経由せず、サーバ同士が直接HTTPで通信する経路。2章
認可コードフロー(authorization code flow): 権限付与として認可コードを使い、フロントチャネルで認可コードを受け取り、バックチャネルでアクセストークンと交換する手順。RFC 6749 4.1節が定める。3章
認可コード(authorization code): 認可サーバがリソースオーナーの許可を得た後に発行する、短命で1回限りの値。クライアントIDとリダイレクトURIに結びつく。3章
エンドポイント(endpoint): 特定の役割を持つHTTPのURL。3章
認可エンドポイント(authorization endpoint): ブラウザ経由でリソースオーナーと対話し、権限付与を得るための認可サーバのURL。3章
トークンエンドポイント(token endpoint): クライアントが権限付与をアクセストークンと交換するための認可サーバのURL。3章
リダイレクトエンドポイント(redirection endpoint): 認可サーバがブラウザ経由で認可レスポンスを返す先の、クライアントのURL。3章
リダイレクトURI(redirection URI): リダイレクトエンドポイントのURI。事前に登録し、認可サーバは完全一致で比較する。3章
トークンレスポンス(token response): トークンエンドポイントが成功時に返すJSONのレスポンス。RFC 6749 5.1節が定める。4章
スコープ(scope): アクセストークンが許可するアクセスの範囲。空白区切りの文字列の並びで表し、意味は認可サーバが決める。4章
最小権限(least privilege): 処理に与える権限を、その処理に必要な最小の範囲に限るという原則。4章
リフレッシュトークン(refresh token): 新しいアクセストークンを取得するための資格情報。認可サーバにだけ送り、リソースサーバには送らない。4章
PKCE(Proof Key for Code Exchange): クライアントが認可リクエストごとに作る code_verifier の変換値を認可リクエストで送り、トークンリクエストで code_verifier を送って認可サーバに照合させることで、認可コードを要求したクライアントのインスタンスに結びつける OAuth 2.0 の拡張。RFC 7636 で定義される。9章
code_verifier: PKCE でクライアントが認可リクエストごとに作る、43〜128文字の非予約文字からなる暗号学的な乱数の文字列。トークンリクエストで送る。9章
code_challenge: PKCE で code_verifier から code_challenge_method の変換で作り、認可リクエストで送る値。9章
code_challenge_method: PKCE で code_verifier から code_challenge を作る変換の方式を示すパラメータ。S256 か plain で、省略時は plain。9章
S256: code_challenge を BASE64URL(SHA256(ASCII(code_verifier))) として作る PKCE の変換方式。サーバが必ず実装する方式で、使えるクライアントは必ず使う。9章
plain: code_challenge を code_verifier と同じ値にする PKCE の変換方式。認可リクエストを読める攻撃者を防げないため、新しい実装では使わない。9章
認可サーバメタデータ(OAuth 2.0 Authorization Server Metadata): Discovery の仕組みを OAuth 2.0 の認可サーバ向けに一般化した仕様と、その JSON 文書。RFC 8414。既定の well-known URI は /.well-known/oauth-authorization-server で、issuer のホストとパスの間に挿入する。10章
code_challenge_methods_supported: 認可サーバが対応する PKCE の code_challenge_method を並べるメタデータ項目。RFC 8414 が定める。10章
認可コードの束縛(authorization code binding): 認可コードを発行した時点のクライアント、redirect_uri、code_challenge、nonce、ユーザーなどをコードと一緒に保存し、交換のときに照合すること。漏洩したコードを第三者が使えなくする。12章
ワンタイム性(one-time use): 認可コードが1回しか交換できない性質。OP は照合の前にコードを取り出して削除し、2回目の使用を拒否する。12章
invalid_client: クライアント認証に失敗したことを表すトークンエンドポイントのエラーコード。Authorization ヘッダで認証を試みた場合は 401 と WWW-Authenticate ヘッダで返す。12章
invalid_grant: 認可コードが無効、期限切れ、失効済み、redirect_uri の不一致、別クライアントへの発行である場合と、PKCE の検証に失敗した場合のトークンエンドポイントのエラーコード。12章
refresh_token グラント(refresh token grant): grant_type を refresh_token にして、リフレッシュトークンをトークンエンドポイントに送り、新しいアクセストークンを得る手続き。スコープは縮小できるが拡大できない。15章
リフレッシュトークンローテーション(refresh token rotation): リフレッシュのたびに新しいリフレッシュトークンを発行し、使われたリフレッシュトークンを無効にする方式。漏洩したトークンの使用を検知する目的で使う。15章
トークンファミリー(token family): 1つの認可から始まり、ローテーションで置き換えられていくリフレッシュトークンの系列。再利用を検知したときに一括で失効させる単位。15章
再利用検知(reuse detection): 使用済みのリフレッシュトークンが再び提示されたことを検出し、漏洩とみなしてトークンファミリーを失効させること。15章
スライディング有効期限(sliding expiration): 最後に使われた時刻から一定期間で切れる有効期限。使われるたびに延びる。アイドルタイムアウトとも呼ぶ。15章
絶対有効期限(absolute expiration): 最初の認可から一定期間で切れる有効期限。使用の頻度にかかわらず延びない。15章
拡張グラント(extension grant): grant_typeに絶対URIを指定し、必要なパラメータを加えて使う、RFC 6749 4.5節の仕組みで追加されたグラント。20章
クライアントクレデンシャルグラント(client credentials grant): クライアントが自分自身の資格情報だけでアクセストークンを得るグラント。利用者は関与せず、機密クライアントだけが使う。RFC 6749 4.4節。20章
ROPC(Resource Owner Password Credentials grant): 利用者がクライアントにユーザー名とパスワードを入力し、クライアントがそれをトークンエンドポイントに送るグラント。RFC 9700で使用禁止、OAuth 2.1で削除。20章
完全一致比較(exact string matching): 2つの文字列を正規化せずに1文字ずつ比べる方法。RFC 9700 はリダイレクト URI の比較にこれを求め、例外はループバックのポート番号だけとする。22章

OpenID Connect

OpenID Connect(OIDC): OAuth 2.0 を前提にして、エンドユーザーの認証の結果とエンドユーザーの属性をクライアントへ伝える方法を定めた仕様群。中心は OpenID Connect Core 1.0。6章
OP(OpenID Provider、OpenID プロバイダ): エンドユーザーを認証し、その結果とエンドユーザーの属性をクレームとして RP に提供できる OAuth 2.0 の認可サーバ。6章
RP(Relying Party、リライングパーティ): エンドユーザーの認証とクレームを OP に求める OAuth 2.0 のクライアント。OP が行った認証の結果に依拠する。6章
エンドユーザー(End-User): OpenID Connect における人間の利用者。OAuth 2.0 のリソースオーナーのうち人間であるものに相当する。6章
IDトークン(ID Token): OP がエンドユーザーを認証した結果を、誰が・いつ・どの発行者によって・どのクライアントのために認証されたかを表すクレームとして書いた、署名付きの JWT。6章
クレーム(claim): ある主体について主張された情報。JSON オブジェクトの名前と値の組として書かれる。6章
openid スコープ(openid scope): 認可リクエストが OpenID Connect の認証リクエストであることを示すスコープ値。含まないリクエストの動作は OpenID Connect では規定されない。6章
UserInfo エンドポイント(UserInfo Endpoint): アクセストークンを Bearer トークンとして受け付け、エンドユーザーのクレームを返す、OP が提供する保護されたリソース。応答の sub は IDトークンの sub と照合する。6章
標準クレーム(Standard Claims): name、email、email_verified など、エンドユーザーの属性の名前・型・意味を OP の間で揃えるために OpenID Connect Core 1.0 5.1節が定めるクレームの集まり。6章
sub(subject): JWT の主題となる主体の識別子。IDトークンでは、発行者の中で一意かつ再割り当てされないエンドユーザーの識別子で、iss との組でユーザーを識別する。6章
IdP(Identity Provider、アイデンティティプロバイダ): エンドユーザーを認証し、その結果を他のサービスに提供するサーバの一般的な呼び名。OpenID Connect の IdP が OP である。6章
SSO(single sign-on、シングルサインオン): 1つの IdP に一度ログインすれば、その IdP を使う複数のサービスに改めて認証情報を入力せずにログインできる状態。6章
フェデレーション(federation、認証連携): 組織や事業者の境界を越えて、ある組織の IdP による認証結果を別の組織のサービスが受け入れる関係。6章
IDトークン検証(ID token validation): 受け取った IDトークンが、信頼する OP の発行したもので、自分宛てで、有効期間内で、自分の送った認証リクエストへの応答であることを確かめる処理。OpenID Connect Core 1.0 3.1.3.7節が手順を定める。8章
azp(authorized party): IDトークンが発行された相手の client_id を表すクレーム。この仕様の範囲外の拡張を使う場合にだけ現れる。8章
auth_time: エンドユーザーの認証が行われた時刻を表すクレーム。max_age を要求した場合は必須になる。iat(IDトークンの発行時刻)とは異なる。8章
nonce: RP が認証リクエストごとに生成し、OP が IDトークンにそのまま入れて返す推測できない値。IDトークンをブラウザのセッションに結びつけ、リプレイ攻撃を防ぐ。8章
acr(Authentication Context Class Reference): 行われた認証が満たした認証コンテキストクラス(同等とみなす認証方法の集まり)を表すクレーム。8章
amr(Authentication Methods References): 認証に使われた方法の識別子の配列を表すクレーム。値は RFC 8176 の IANA 登録簿に登録されたものを使うことが推奨され(SHOULD)、登録されていない値は当事者間で意味を合意して使う。8章
at_hash(access token hash): アクセストークンの ASCII のバイト列を IDトークンの alg のハッシュ関数でハッシュし、左半分を Base64url で符号化した値を表すクレーム。IDトークンとアクセストークンを結びつける。8章
request_parameter_supported: OP が request パラメータに対応しているかを表す Discovery のメタデータ項目。省略時の値は false。10章
request_uri_parameter_supported: OP が request_uri パラメータに対応しているかを表す Discovery のメタデータ項目。省略時の値は true なので、対応しない OP は false を明示する。10章
Discovery(OpenID Connect Discovery 1.0): RP が OP の設定値(エンドポイントの URL、署名鍵の場所、対応アルゴリズムなど)を、issuer 識別子から決まる URL で取得する方法を定めた仕様。10章
issuer 識別子(Issuer Identifier): OP を表す、大文字小文字を区別する https の URL。クエリとフラグメントを含まない。メタデータの issuer と IDトークンの iss に入り、正規化せずに文字列の完全一致で比較する。10章
OpenID プロバイダメタデータ(OpenID Provider Metadata): Discovery で OP が公開する設定値の JSON 文書の項目。issuer、authorization_endpoint、jwks_uri などを含む。10章
jwks_uri: OP の JWK Set 文書の URL を示すメタデータ項目。必須で、https を使い、秘密鍵や共通鍵を含めてはならない。10章
id_token_signing_alg_values_supported: OP が IDトークンの署名に使う alg の値を並べるメタデータ項目。RP のアルゴリズム許可リストの元になる。Discovery は RS256 を含めることを必須とする。10章
UserInfo レスポンス(UserInfo Response): UserInfo エンドポイントが返すクレームの集まり。JSON なら application/json で返し、sub を常に含め、返さないクレームは名前ごと省く。10章
openidconnect クレート(openidconnect crate): OpenID Connect の RP 側の処理(Discovery、認可リクエスト、トークン交換、IDトークンの検証、UserInfo)を提供する Rust のライブラリ。OAuth 2.0 の部分は oauth2 クレートが担う。11章
コールバック(callback): OP がブラウザをリダイレクトさせて認可レスポンスを届ける先の、RP の処理。リダイレクトエンドポイントを実装したハンドラ。11章
request_not_supported: OP が request パラメータに対応していないことを表す認可エラーのエラーコード。OpenID Connect Core 1.0 3.1.2.6節が定める。12章
request_uri_not_supported: OP が request_uri パラメータに対応していないことを表す認可エラーのエラーコード。OpenID Connect Core 1.0 3.1.2.6節が定める。12章
同意(consent): エンドユーザーが、RP に自分の情報やリソースへのアクセスを許すと意思表示すること。OP は認証の後、RP に情報を渡す前に認可の判断を得なければならない。12章
login_required: prompt=none の認証リクエストを、エンドユーザーの認証なしには完了できないことを表す認可エラーのエラーコード。OpenID Connect Core 1.0 3.1.2.6節が定める。12章
offline_access(offline access scope): エンドユーザーがその場にいないときにもアクセスするためのリフレッシュトークンの発行を要求するスコープ値。OP は明示的な同意を得なければならない。15章
クレームプロバイダ(Claims Provider): OP 以外でエンドユーザーのクレームを発行する主体。集約クレームや分散クレームの発行元になる。18章
email_verified(email_verified claim): OPが、利用者がそのメールアドレスを管理していることを確かめたかを示す真偽値のクレーム。trueは検証を行った時点で管理していたことを意味し、現在の管理は保証しない。18章
アカウントリンク(account linking): 複数の(iss, sub)の組を、RPの1つのローカルアカウントに対応づけること。既存アカウントにログイン中のセッションから明示的に行う。18章
public識別子(public subject identifier): すべてのRPに同じsubを渡す方式の利用者識別子。subject_types_supportedがない場合の既定。18章
pairwise識別子(pairwise subject identifier): セクター識別子ごとに異なるsubを渡す方式の利用者識別子。RPどうしが利用者の行動を結びつけることを防ぐ。OIDC Core 8.1節。18章
セクター識別子(sector identifier): pairwise識別子の計算単位。既定はリダイレクトURIのホスト部分で、sector_identifier_uriを登録した場合はそのURLのホスト部分。18章
sector_identifier_uri(sector_identifier_uri parameter): RPのリダイレクトURIの一覧を格納したJSONファイルを指すhttpsのURL。複数のホスト名で同じpairwise識別子を受け取るために登録する。18章
claims パラメータ(claims request parameter): クレームを1つずつ、返す場所(id_tokenかuserinfo)と条件(essential、value、values)を付けて要求する認証リクエストのパラメータ。値はJSON。18章
Essentialクレーム(Essential Claim): 利用者が求めた操作を円滑に進めるために必要だとRPが示して要求するクレーム。Essentialでも返らないことがある。対になるのは任意のクレーム(Voluntary Claim)。18章
集約クレーム(aggregated claims): クレームプロバイダが署名したJWTを、OPがレスポンスに埋め込んで渡す形式のクレーム。_claim_namesと_claim_sourcesで表す。18章
分散クレーム(distributed claims): クレームを取得できるエンドポイントとアクセストークンだけを渡し、RPが後からクレームプロバイダに問い合わせる形式のクレーム。18章
acr_values(acr_values parameter): RPが望む認証コンテキストのクラスを優先順に空白区切りで並べた認証リクエストのパラメータ。任意のクレームとしての要求になる。18章
max_age(max_age parameter): 利用者が最後に能動的に認証してから許容する経過秒数を指定する認証リクエストのパラメータ。指定するとIDトークンにauth_timeが必須になる。max_age=0はprompt=loginと同じ。18章
prompt(prompt parameter): OPに再認証や同意の画面を出させるか、出させないかを指定する認証リクエストのパラメータ。値はnone、login、consent、select_accountと、拡張仕様のcreate。18章
login_hint(login_hint parameter): 利用者がログインに使いそうな識別子(メールアドレスや電話番号)をOPに伝えるヒント。使うかどうかはOPの判断。18章
id_token_hint(id_token_hint parameter): 以前にそのOPから受け取ったIDトークンを、利用者のセッションについてのヒントとして渡すパラメータ。認証リクエストとRP-Initiated Logoutで使う。18章
インプリシットフロー(implicit flow): 認可エンドポイントがIDトークン(とアクセストークン)をフラグメントで直接返し、トークンエンドポイントを使わないフロー。response_typeはid_tokenかid_token token。現在は推奨されない。19章
ハイブリッドフロー(hybrid flow): 認可エンドポイントが認可コードとIDトークンかアクセストークン(または両方)を同時に返し、RPが認可コードをトークンエンドポイントで交換するフロー。response_typeはcode id_token、code token、code id_token token。19章
c_hash(code hash): 認可コードをIDトークンのalgのハッシュ関数でハッシュし、左半分をBase64urlで表した値のクレーム。IDトークンと同じ応答の認可コードを結びつけ、コードの差し替えを検出する。19章
シングルログアウト(single logout): 1回のログアウト操作で、関係するすべてのRPとOPのセッションを終わらせること。21章
RP-Initiated Logout(RP-Initiated Logout): RPが利用者のブラウザをOPのend_session_endpointへリダイレクトし、OPでのログアウトを依頼する仕組み。OpenID Connect RP-Initiated Logout 1.0。21章
end_session_endpoint(end_session_endpoint metadata): OPのログアウト用エンドポイントのURLを示すDiscoveryメタデータ。httpsでなければならない。21章
post_logout_redirect_uri(post_logout_redirect_uri parameter): ログアウト後にブラウザを戻す先のURI。登録済みの値と完全一致しなければOPはリダイレクトしない。21章
フロントチャネルログアウト(front-channel logout): OPがログアウト完了のページに各RPのfrontchannel_logout_uriを表示するiframeを置き、ブラウザ経由で各RPにログアウトを伝える仕組み。21章
frontchannel_logout_uri(frontchannel_logout_uri metadata): フロントチャネルログアウトでOPがiframeに表示する、RPのログアウト用URL。21章
sid(session ID claim): ある利用者の、あるブラウザでの、あるRPに対するログインのセッションを表す、OPが発行する識別子。IDトークンとログアウトの通知に入り、RPはこれでセッションを特定する。21章
バックチャネルログアウト(back-channel logout): OPがブラウザを経由せず、各RPのbackchannel_logout_uriへログアウトトークンを直接POSTしてログアウトを伝える仕組み。21章
backchannel_logout_uri(backchannel_logout_uri metadata): バックチャネルログアウトでOPがログアウトトークンを送る、RPのURL。OPから到達可能でなければならない。21章
ログアウトトークン(logout token): OPがRPにログアウトを求めるために送る、IDトークンに似たJWT。eventsが必須で、nonceは禁止。typはlogout+jwtが推奨。21章
events クレーム(events claim): ログアウトトークンであることを示すクレーム。メンバー名http://schemas.openid.net/event/backchannel-logoutを含むJSONオブジェクト。21章
session_state(session_state parameter): Session Management 1.0で、OPが認証応答に含める、OPでの利用者のログイン状態を表す文字列。RPにとって中身は意味を持たない。21章
check_session_iframe(check_session_iframe metadata): Session Management 1.0で、RPのページに埋め込み、postMessageでsession_stateを照合させるOPのページのURLを示すDiscoveryメタデータ。21章

トークンとJOSE

Bearerトークン(bearer token): 持っている者なら誰でも使えるトークン。使うときに鍵の所持の証明を必要としない。RFC 6750が定める。4章
b64token: Bearerトークンの値に使える文字の並びを定める構文規則。英数字と-._~+/の1文字以上に、=が0個以上続く。4章
invalid_token: アクセストークンが期限切れ、失効済み、形式不正などで無効であることを示すリソースサーバのエラーコード。401で返す。4章
insufficient_scope: リクエストに必要な権限がアクセストークンのスコープを超えることを示すリソースサーバのエラーコード。403で返す。4章
StringOrURI: RFC 7519 が定める値の型。任意の文字列で、コロンを含む場合は URI でなければならない。iss・sub・aud の値の型。7章
Nested JWT: JWS で署名した JWT を、さらに JWE で暗号化するなど、JWT を入れ子にした形式。7章
CRLF: 改行を表す2文字の並び(復帰 CR と改行 LF)。JSON の改行や空白の違いは署名入力のバイト列を変えるため、JWS では意味の同じ JSON でも署名が一致しない。7章
JOSE(JSON Object Signing and Encryption): JSON を使って署名・MAC・暗号化と鍵を表すための IETF の仕様群。JWS、JWE、JWK、JWA、JWT からなる。7章
JWS(JSON Web Signature): デジタル署名または MAC で保護したメッセージを表すデータ構造。RFC 7515 で定義される。7章
JWE(JSON Web Encryption): 暗号化したメッセージを表すデータ構造。コンパクトシリアライゼーションは5つの部分からなる。RFC 7516 で定義される。7章
JWK(JSON Web Key): 暗号鍵を表す JSON オブジェクト。kty と、鍵の種類ごとのメンバーからなる。RFC 7517 で定義される。7章
JWK Set(JWKS): 複数の JWK を keys メンバーの配列にまとめた JSON オブジェクト。OP は署名鍵の公開鍵を JWK Set で公開する。7章
JWA(JSON Web Algorithms): JWS・JWE・JWK で使うアルゴリズムの名前と計算方法を定めた仕様。RFC 7518。7章
JWT(JSON Web Token): クレームの集合を JSON オブジェクトとして表し、JWS または JWE で保護して伝送する形式。RFC 7519 で定義される。7章
JOSE ヘッダ(JOSE Header): JWS や JWE の暗号処理を説明するパラメータ(alg、kid など)の JSON オブジェクト。JWS のコンパクトシリアライゼーションでは全体が署名または MAC の対象になり、JWE では認証付き暗号の追加認証データとして完全性が保護される。7章
alg(algorithm): JOSE ヘッダで、JWS を保護したアルゴリズムを示すパラメータ。必須。検証側はこの値に従わず、許可リストと照合する。7章
kid(key ID): JOSE ヘッダや JWK で鍵を識別する値。JWS の kid は検証に使う鍵を JWK Set から選ぶためのヒントである。7章
typ(type): JOSE ヘッダで、JWS や JWT 全体のメディアタイプを宣言するパラメータ。JWT では値 JWT が推奨される。7章
コンパクトシリアライゼーション(Compact Serialization): JWS の3つの部分(JWE は5つ)をそれぞれ Base64url で符号化し、. で連結した文字列の形式。OpenID Connect はこの形式だけを使う。7章
JSON シリアライゼーション(JSON Serialization): JWS や JWE を JSON オブジェクトのメンバーとして表す形式。複数の署名を付けられる。7章
署名入力(JWS Signing Input): JWS の署名または MAC の計算対象。BASE64URL(ヘッダ) と BASE64URL(ペイロード) を . で連結した ASCII 文字列で、コンパクト形式の2つ目の . より前の部分に等しい。7章
登録済みクレーム(registered claim names): RFC 7519 4.1節が IANA の登録簿に登録した7つの JWT クレーム。iss、sub、aud、exp、nbf、iat、jti。7章
iss(issuer): JWT を発行した主体を識別するクレーム。IDトークンでは OP の Issuer Identifier(https の URL)で、RP の設定値と完全一致で照合する。7章
aud(audience): JWT の宛先を識別するクレーム。文字列または文字列の配列。受信者は自分を示す値が含まれなければ拒否する。7章
exp(expiration time): この時刻以降は JWT を受け入れてはならない有効期限を表すクレーム。NumericDate で表す。7章
nbf(not before): この時刻より前は JWT を受け入れてはならない有効開始時刻を表すクレーム。7章
iat(issued at): JWT が発行された時刻を表すクレーム。7章
jti(JWT ID): JWT の一意な識別子を表すクレーム。同じ JWT の再利用の検出に使える。7章
NumericDate: 1970-01-01T00:00:00Z(UTC)からの秒数をうるう秒を無視して表した JSON の数値。JWT の時刻のクレームに使う。7章
HS256: HMAC SHA-256 による MAC を表す JWA のアルゴリズム名。署名側と検証側が同じ秘密の鍵を共有する。7章
RS256: RSASSA-PKCS1-v1_5 と SHA-256 による RSA 署名を表す JWA のアルゴリズム名。OpenID Connect の IDトークンの既定値。7章
ES256: P-256 曲線と SHA-256 による ECDSA 署名を表す JWA のアルゴリズム名。署名は R と S を32バイトずつ連結した64バイト。7章
JWK Thumbprint: JWK の必須メンバーだけをメンバー名の辞書順・空白なしで並べた JSON のハッシュ値。同じ鍵からは常に同じ値が得られる。RFC 7638 で定義される。7章
kty(key type): JWK で鍵の種類(EC、RSA、oct など)を表す必須のメンバー。7章
use(public key use): JWK で公開鍵の用途を表すメンバー。sig(署名の検証)か enc(暗号化)。7章
crv(curve): 楕円曲線の JWK で曲線(P-256 など)を表すメンバー。7章
x / y(x coordinate / y coordinate): 楕円曲線の公開鍵の JWK で、曲線上の点の座標を曲線の大きさのバイト列にして Base64url で符号化したメンバー。7章
n / e(modulus / exponent): RSA の公開鍵の JWK で、法と公開指数をビッグエンディアンのバイト列にして Base64url で符号化したメンバー。65537 の e は AQAB になる。7章
crit(critical): 受信者が理解して処理しなければならない拡張のヘッダパラメータ名を列挙する JWS のヘッダパラメータ。列挙された拡張を受信者が理解しない場合、その JWS は無効になる。RFC 7515 4.1.11節。8章
不透明トークン(opaque token): それ自体には意味のある情報を含まない、推測できないランダムな文字列のトークン。内容は認可サーバの記録にだけあり、リソースサーバは問い合わせて検証する。14章
自己完結型トークン(self-contained token): 検証に必要な情報をトークン自体に含め、発行者が署名したトークン。構造化トークンとも呼ぶ。JWT アクセストークンが代表例。14章
at+jwt(JWT access token type): RFC 9068 の JWT アクセストークンであることを示す typ ヘッダの値。メディアタイプ application/at+jwt から application/ を省いたもの。14章
暗号アルゴリズムの移行可能性(cryptographic agility): アルゴリズムに弱点が見つかったとき、形式を変えずに別のアルゴリズムへ移れるようにする設計。JWS がヘッダに alg を置く理由。23章
JWT BCP(JSON Web Token Best Current Practices): JWT の安全な実装と運用の規則をまとめた RFC 8725(BCP 225)。改訂版が draft-ietf-oauth-rfc8725bis として策定中。23章
Unsecured JWS(Unsecured JWS): alg に none を指定し、署名部を空にした JWS。アプリケーションがオブジェクトごとに許可した場合を除き受け入れてはならない。23章
jku(JWK Set URL): 署名鍵を含む JWK Set の URL を示す JOSE ヘッダパラメータ。検証器が従うと攻撃者の鍵の受け入れや SSRF の原因になる。23章
x5u(X.509 URL): 署名鍵の X.509 証明書(チェーン)の URL を示す JOSE ヘッダパラメータ。jku と同じ理由で検証に使わない。23章
x5c(X.509 Certificate Chain): 署名鍵の X.509 証明書チェーンを Base64 で埋め込む JOSE ヘッダパラメータ。チェーンを信頼できる認証局まで検証しなければ使えない。23章
JWT の取り違え(cross-JWT confusion): ある目的で発行された JWT が別の目的に転用されること。置換攻撃の一種。ID トークンをアクセストークンとして使う例が典型。23章
明示的型付け(explicit typing): JWT の種類ごとに異なる typ ヘッダの値(at+jwt など)を付け、検証側がそれを確かめることで JWT の取り違えを防ぐ方法。23章
完全指定アルゴリズム(fully-specified algorithm): 曲線・鍵導出関数・ハッシュ関数を含めて暗号処理を一意に決めるアルゴリズム識別子。JOSE の ES256、RFC 9864 が登録した Ed25519 など。23章
多相アルゴリズム(polymorphic algorithm): 処理を決めるために鍵の曲線など識別子以外の情報を必要とするアルゴリズム識別子。JOSE の EdDSA で、RFC 9864 により非推奨。23章
SD-JWT(Selective Disclosure for JWTs): JWT で選択的開示を行う仕様。署名する JWT にはクレームのダイジェストだけを入れ、値は Disclosure として署名の外に置く。RFC 9901(2025年11月)。27章
選択的開示(selective disclosure): 署名済みの資格情報のうち、一部のクレームだけを相手に見せること。27章
Disclosure: ソルト、クレーム名、クレームの値を要素とする JSON 配列を Base64url でエンコードした文字列。配列要素の場合はクレーム名を含まない2要素の配列になる。27章
_sd: SD-JWT のペイロードで、その階層の選択的に開示できるクレームの Disclosure のダイジェストを並べた配列。27章
_sd_alg: SD-JWT のダイジェストに使ったハッシュ関数を示すクレーム。ない場合は sha-256 とみなす。27章
デコイダイジェスト(decoy digest): どのクレームにも対応しないダミーのダイジェスト。隠しているクレームの数を検証者に推測させないために _sd に加える。27章
発行者(Issuer): SD-JWT を作成して署名するエンティティ。27章
保有者(Holder): 発行者から SD-JWT を受け取って保持し、検証者に提示するエンティティ。利用者本人とその端末のソフトウェアを指す。27章
検証者(Verifier): 保有者から提示された SD-JWT を検証し、クレームを取り出すエンティティ。27章
鍵束縛(Key Binding): 提示した保有者が、SD-JWT の cnf に含まれる公開鍵に対応する秘密鍵を持つことを、提示のたびに署名で示す仕組み。27章
鍵束縛 JWT(Key Binding JWT、KB-JWT): 保有者が提示のたびに作る、typ が kb+jwt の JWT。nonce、aud、iat、sd_hash を含む。27章
sd_hash: 鍵束縛 JWT に含める、提示する SD-JWT(発行者の JWT と選んだ Disclosure)全体のハッシュ。鍵束縛 JWT を別の Disclosure の組み合わせに付け替えることを防ぐ。27章
正規化(canonicalization): 意味が同じ文書を、決まった1つのバイト列に変換する処理。XML 署名では署名の前に必要になる。27章

暗号

RSASSA-PSS: 乱数を使うパディング方式を用いる RSA 署名。JWS では PS256 などの alg 値で表す。5章
OWASP(Open Worldwide Application Security Project): Web アプリケーションのセキュリティに関する資料やチェックリストを公開している非営利の団体。5章
完全性(integrity): データが途中で変更されていないこと。5章
真正性(authenticity): データが、名乗っている送信者によって作られたこと。5章
機密性(confidentiality): データの内容が、許された者以外に読まれないこと。5章
ハッシュ関数(hash function): 任意の長さの入力から固定長の出力を計算する関数。本書では原像困難性などを持つ暗号学的ハッシュ関数を指す。5章
ダイジェスト(digest): ハッシュ関数の出力。ハッシュ値とも呼ぶ。5章
SHA-256: NISTがFIPS 180-4で定める、256ビット(32バイト)のダイジェストを出力するハッシュ関数。5章
原像(preimage): あるダイジェストを出力する入力。5章
原像困難性(preimage resistance): ダイジェストから原像を見つけることが計算上困難である性質。5章
第二原像困難性(second preimage resistance): ある入力と同じダイジェストになる別の入力を見つけることが計算上困難である性質。5章
衝突(collision): 同じダイジェストになる、異なる2つの入力の組。5章
衝突困難性(collision resistance): 衝突を見つけることが計算上困難である性質。総当たりの目安は出力のビット数の半分を指数とする回数。5章
MAC(message authentication code): メッセージと秘密の鍵からタグを計算し、完全性と真正性を保証する仕組み。5章
HMAC(hash-based MAC): ハッシュ関数を使ってMACを構成する方式。RFC 2104が定める。JWSのHS256はHMAC-SHA256を使う。5章
共通鍵暗号(symmetric-key cryptography): 送信者と受信者が同じ鍵を共有して使う暗号方式。5章
公開鍵暗号(public-key cryptography): 数学的に対応する秘密鍵と公開鍵の組を使う暗号方式。5章
鍵ペア(key pair): 公開鍵暗号で組にして使う秘密鍵と公開鍵。5章
秘密鍵(private key): 鍵ペアのうち、持ち主だけが保持し外部に出さない鍵。署名の生成や復号に使う。5章
公開鍵(public key): 鍵ペアのうち、誰に知られてもよい鍵。署名の検証や暗号化に使う。5章
デジタル署名(digital signature): 秘密鍵でメッセージの署名を計算し、公開鍵で検証することで、完全性と真正性を保証する仕組み。機密性は提供しない。5章
RSA: 大きな数の素因数分解の困難さに基づく公開鍵暗号の方式。JWSのRS256、PS256が使う。5章
ECDSA(Elliptic Curve Digital Signature Algorithm): 楕円曲線上の演算を使う署名方式。署名ごとに秘密の乱数を使う。5章
楕円曲線(elliptic curve): y² = x³ + ax + bの形の式を満たす点の集合と、点の加算の規則。暗号では有限体の上で定義したものを使う。5章
P-256: NISTが定めた256ビットの楕円曲線。secp256r1とも呼ぶ。ECDSA、P-256、SHA-256の組がJWSのES256。5章
Ed25519: Curve25519から作られたEdDSAの署名方式。RFC 8032が定める。同じメッセージには常に同じ署名を生成する。JOSEのalg値はRFC 9864でEd25519になった。5章
PKCS#8: 秘密鍵を、アルゴリズムの識別子とともにASN.1で符号化して格納する標準の形式。5章
暗号化(encryption): データを鍵がなければ読めない形に変換し、機密性を保証する処理。5章
Base64url: Base64の+を-に、/を_に置き換えた変種。RFC 4648の5節が定める。JOSEではパディングを付けない。5章
パディング(padding): Base64で、入力の長さが3の倍数でないときに出力の末尾に付ける=。5章
乱数生成器(random number generator): 予測できない数の列を出力する仕組み。5章
CSPRNG(cryptographically secure pseudo-random number generator): 出力をいくら観測しても次や過去の出力を予測できないよう設計された擬似乱数生成器。シードにOSの乱数を使う。5章
エントロピー(entropy): 値の予測できなさの量。本書では取りうる場合の数を2の何乗かで表したビット数として扱う。5章
ソルト(salt): パスワードと一緒にハッシュに入力する、利用者ごとのランダムな値。秘密ではない。5章
パスワードハッシュ(password hashing): パスワードの保存のために、計算に時間とメモリがかかるよう設計された関数。5章
Argon2: Password Hashing Competition(2015年)で選ばれたパスワードハッシュ関数。RFC 9106が定める。変種のArgon2idが推奨される。5章
scrypt: メモリを多く使う設計のパスワードハッシュ関数。RFC 7914が定める。5章
bcrypt: 1999年から使われているパスワードハッシュ関数。入力は72バイトまで。5章
PBKDF2: HMACを指定回数だけ繰り返すパスワードベースの鍵導出関数。RFC 8018が定める。5章
ring: ハッシュ関数、HMAC、署名、乱数などの暗号の部品を、誤用しにくいAPIで提供するRustのクレート。5章
Ed448: 448ビットの楕円曲線 Edwards448 を使う EdDSA 署名。Ed25519 より大きな安全性の余裕を持つ。7章
署名検証(signature verification): JWS の署名が、信頼する発行者の鍵で署名入力に対して作られたものであることを確かめる処理。成功するまでペイロードの値を使わない。8章
XOR(排他的論理和): 2つのビットが異なれば1、同じなら0を返す演算。定数時間比較では、全バイトの XOR を集約して一致を判定する。12章
ES256 署名鍵(ES256 signing key): ES256(P-256 と SHA-256 による ECDSA)の署名に使う秘密鍵。OP は IDトークンと JWT アクセストークンに署名し、公開鍵だけを JWKS で公開する。12章
X.509 証明書(X.509 certificate): 公開鍵とその持ち主を示す名前(サブジェクト)などを組にし、発行者が署名したデータ構造。TLS で使われる。13章
認証局(certificate authority、CA): X.509 証明書を発行し署名する、信頼された発行者。受け取った側は認証局の署名をたどって証明書を検証する。13章
PKI(public key infrastructure、公開鍵基盤): 認証局が X.509 証明書を発行し、受け取った側が認証局の署名をたどって検証する、証明書の発行と検証の仕組み全体。13章
DN(distinguished name、識別名): X.509 証明書のサブジェクトや発行者を表す構造化された名前。tls_client_auth では登録値との照合に使える。13章
SAN(subject alternative name、サブジェクト代替名): X.509 証明書に、DNS 名、URI、IP アドレス、メールアドレスなどの別名を持たせる拡張。13章
自己署名証明書(self-signed certificate): 発行者と持ち主が同じ X.509 証明書。認証局による保証はなく、事前に登録した証明書との一致で信頼する。13章
AES(Advanced Encryption Standard): 広く使われている共通鍵ブロック暗号。pairwise 識別子を暗号化で作る方式などで使われる。18章
PEM: DER で符号化した鍵や証明書を Base64 にし、-----BEGIN ...----- の行で囲んだテキスト形式。23章
ECDH-ES: 楕円曲線 Diffie-Hellman で使い捨ての鍵を合意し、そこから暗号化の鍵を導く JWE の鍵管理方式。23章
DER(Distinguished Encoding Rules): ASN.1 のデータを一意のバイト列にする符号化規則。ECDSA の署名では SEQUENCE の中に r と s の INTEGER を入れた可変長の形式になり、JWS の64バイトの raw 形式と異なる。23章
署名の展性(signature malleability): 有効な署名から、秘密鍵を使わずに同じメッセージに対する別の有効な署名を作れる性質。ECDSA では (r, s) が有効なら (r, n - s) も有効。23章

クライアントと認証

クライアント認証(client authentication): トークンエンドポイントへのリクエストを送ってきたのが登録されたクライアント本人であることを、認可サーバが確かめる処理。3章
クライアントシークレット(client secret): 認可サーバとクライアントだけが知る、クライアント認証用の秘密の文字列。3章
パブリッククライアント(public client): クライアントシークレットなどの認証情報を安全に保持できないクライアント。ネイティブアプリやブラウザ上の JavaScript アプリケーション。9章
機密クライアント(confidential client): クライアントシークレットなどの認証情報を安全に保持でき、トークンエンドポイントでクライアント認証を行えるクライアント。サーバ上の Web アプリケーションが典型。9章
多要素認証(multi-factor authentication、MFA): 知っているもの、持っているもの、本人の特徴のうち、種類の異なる2つ以上の要素を組み合わせる認証の方法。12章
token_endpoint_auth_method(token endpoint authentication method): クライアントがトークンエンドポイントで使う認証方式を宣言するクライアントメタデータ。RFC 7591 が定め、省略時の既定値は client_secret_basic。13章
client_secret_basic(client secret basic): client_id とクライアントシークレットをそれぞれ form-urlencoded で符号化してから HTTP Basic 認証の形で送るクライアント認証方式。符号化の有無で実装間の不一致が起きやすい。13章
client_secret_post(client secret post): client_id と client_secret をトークンリクエストの本文のパラメータとして送るクライアント認証方式。OAuth 2.1 の draft ではサポートが必須とされる。13章
client_secret_jwt(client secret JWT): クライアントシークレットを鍵とする HMAC で JWT を作り、クライアントアサーションとして送るクライアント認証方式。シークレットは送られないが、認可サーバは鍵として使える形でシークレットを保存する。13章
private_key_jwt(private key JWT): クライアントが秘密鍵で署名した JWT をクライアントアサーションとして送り、認可サーバが登録済みの公開鍵で検証するクライアント認証方式。認可サーバは公開鍵だけを保存する。13章
クライアントアサーション(client assertion): クライアントが自分の身元、宛先の認可サーバ、有効期限などを書き、署名または MAC を付けた JWT。client_assertion パラメータで送る。13章
client_assertion_type(client assertion type): クライアントアサーションの種類を示すパラメータ。JWT の場合は urn:ietf:params:oauth:client-assertion-type:jwt-bearer に固定される。13章
client_assertion(client assertion parameter): クライアントアサーションの JWT を1つだけ入れて送るトークンリクエストのパラメータ。13章
mTLS(mutual TLS、相互 TLS): TLS ハンドシェイクでクライアントも証明書を提示し、秘密鍵の所有を証明して、サーバとクライアントが互いを確認する TLS の使い方。13章
tls_client_auth(PKI mutual-TLS method): 認証局が発行したクライアント証明書を使う mTLS のクライアント認証方式。証明書チェーンを検証し、サブジェクト名を登録値と照合する。13章
self_signed_tls_client_auth(self-signed certificate mutual-TLS method): 自己署名証明書を使う mTLS のクライアント認証方式。証明書チェーンを検証せず、登録済みの証明書との一致で認証する。13章
動的クライアント登録(dynamic client registration): クライアントの登録を、メタデータの JSON を送る HTTP の API で行う仕組み。RFC 7591 が定める。13章
クライアント登録エンドポイント(client registration endpoint): 動的クライアント登録で、クライアントがメタデータを POST する認可サーバのエンドポイント。13章
初期アクセストークン(initial access token): クライアント登録エンドポイントの利用を許可するために要求される Bearer トークン。入手方法は RFC 7591 の範囲外。13章
ソフトウェアステートメント(software statement): クライアントソフトウェアのメタデータを JWT にまとめ、発行者が署名または MAC を付けたもの。登録時に提示し、iss を必ず含む。13章
Client ID Metadata Document(CIMD): クライアントが自分のメタデータを https の URL で公開し、その URL を client_id として使う仕組み。認可サーバは URL から文書を取得する。IETF で策定中の Internet-Draft。13章

攻撃と防御

CSRF(cross-site request forgery): 攻撃者が用意したページやリンクにより、被害者のブラウザに意図しないリクエストを送らせる攻撃。認可コードフローでは攻撃者の認可コードを送り込むために使われる。3章
タイミング攻撃(timing attack): 処理時間の違いから秘密の情報を推測する攻撃。5章
定数時間比較(constant-time comparison): 入力の内容に関係なく同じ時間で終わる比較。秘密の値の比較に使う。5章
トークン置換攻撃(token substitution attack): 別の文脈で発行されたトークンを差し替えて提示し、正規のクライアントに受け入れさせる攻撃の総称。他のクライアント宛てのアクセストークンでログインさせる攻撃が典型で、IDトークンの aud の検査で防ぐ。6章
alg の固定(algorithm pinning、アルゴリズム許可リスト): 受け入れる署名アルゴリズムの一覧を検証側の設定として持ち、JOSE ヘッダの alg が一覧にない JWS を署名検証の前に拒否すること。鍵ごとにアルゴリズムを1つに限定する検査と組み合わせる。8章
ログインCSRF(login CSRF): 攻撃者が自分のアカウントの認可レスポンスを被害者のブラウザに読み込ませ、被害者を攻撃者のアカウントで RP にログインさせる攻撃。state、nonce、PKCE のいずれでも防げる。9章
リプレイ攻撃(replay attack): 正規のやり取りで一度使われたメッセージやトークンを記録しておき、後で再び送って受け入れさせる攻撃。9章
認可コード横取り攻撃(authorization code interception attack): 認可レスポンスのリダイレクトで受け渡される認可コードを攻撃者が途中で取得し、トークンエンドポイントでアクセストークンに交換する攻撃。PKCE で防ぐ。9章
コードインジェクション(authorization code injection): 攻撃者が盗んだ認可コードを正規のクライアントとの自分のセッションに注入し、自分のセッションを被害者のリソースや身元に結びつける攻撃。クライアント認証では防げず、PKCE または nonce で防ぐ。9章
SSRF(server-side request forgery): 攻撃者がサーバに任意の宛先へ HTTP リクエストを送らせ、外部からは届かない内部のアドレスに到達しようとする攻撃。RP が OP からのリダイレクトを追跡しないのはこの対策。11章
セッション固定攻撃(session fixation): 攻撃者が知っているセッションIDを被害者のブラウザに使わせ、被害者のログイン後に同じIDで被害者として振る舞う攻撃。ログイン成功時にセッションIDを再発行して防ぐ。11章
PKCE ダウングレード攻撃(PKCE downgrade attack): code_challenge を付けずに認可リクエストを送らせ、PKCE の検証を省かせる攻撃。認可サーバは code_challenge があった場合にだけ code_verifier を含むトークンリクエストを受け付けて防ぐ。12章
X-Frame-Options ヘッダ(X-Frame-Options header field): ページを他のページの frame や iframe に表示してよいかを指定するレスポンスヘッダ。DENY で表示を禁じ、クリックジャッキングを防ぐ。12章
トークンスキャン攻撃(token scanning attack): イントロスペクションエンドポイントなどに任意の文字列を送り、有効と判定される値を総当たりで探す攻撃。呼び出し元の認証で防ぐ。14章
Heartbleed: 2014年に公表された OpenSSL の脆弱性(CVE-2014-0160)。サーバのメモリの内容を外部から読み出せたため、通信中のトークンや鍵が漏洩しうる例として挙げられる。16章
格下げ攻撃(downgrade attack): 送信者制約や署名付きリクエストなどの強い保護を使わず、より弱い方式で要求を受け入れさせて保護を回避する攻撃。16章
否認防止(non-repudiation): 送信者が、あるメッセージを送ったという事実を後から否定できないようにする性質。署名をメッセージとともに保存することで実現する。17章
ミックスアップ攻撃(mix-up attack): 複数の認可サーバと連携するクライアントに、ある認可サーバが発行した認可コードやトークンを、攻撃者の認可サーバへ送らせる攻撃。iss パラメータの検査などで防ぐ。17章
アカウント乗っ取り(account takeover): 正規の認証を経て、他人のアカウントの操作権を得る攻撃。RPがemailなどをアカウントの照合キーに使うと成立する。18章
アクセストークンインジェクション(access token injection): 攻撃者が盗んだアクセストークンを正規のクライアントの認可応答に差し込み、被害者として振る舞わせる攻撃。OpenID Connectではat_hashとnonceで検出する。RFC 9700 4.6節。19章
クロスデバイス同意フィッシング(cross-device consent phishing、CDCP): クロスデバイスフローの端末間の経路が認証されないことを利用し、攻撃者が開始したフローのコードを別の文脈で被害者に入力させ、認可を与えさせる攻撃。多要素認証を導入していても成立する。20章
ARP スプーフィング(ARP spoofing): 同じネットワーク内で偽の ARP 応答を送り、他の端末の通信を自分の端末に向けさせる攻撃。ネットワーク攻撃者の手段の例。22章
脅威モデル(threat model): 保護する対象、想定する攻撃者、起こりうる攻撃とその対策を体系的に列挙したもの。OAuth 2.0 では RFC 6819 が記述した。22章
攻撃者モデル(attacker model): 攻撃者が実行できる操作(読めるメッセージ、改ざんできるメッセージ、運用できるエンドポイント)を列挙した前提。具体的な攻撃はこの能力から導く。22章
Web 攻撃者(web attacker): 任意の数のサーバ・ブラウザ・クライアント・認可サーバを運用し、ユーザーを任意の URI へ誘導できるが、自分宛てでないメッセージは読めない攻撃者。RFC 9700 の A1。22章
ネットワーク攻撃者(network attacker): Web 攻撃者の能力に加えて通信経路を制御し、暗号で保護されていないメッセージを盗聴・改ざん・偽装できる攻撃者。RFC 9700 の A2。22章
トークン漏洩(token leakage): 認可コードやアクセストークンなどの資格情報が、TLS を破られることなく URL・ログ・ヘッダ・設定ミスを経由して第三者に渡ること。RFC 9700 の A3〜A5 はこれを前提にした攻撃者。22章
オープンリダイレクタ(open redirector): クエリパラメータで受け取った任意の URI へユーザーのブラウザを転送する、Web サーバ上のエンドポイント。フラグメントの付け直しと組み合わさるとトークンの漏洩経路になる。22章
クリックジャッキング(clickjacking): 攻撃者のページに正規のページを透明に近い iframe で重ね、ユーザーに正規のページのボタンを意図せず押させる攻撃。UI の偽装とも呼ぶ。22章
LDAP インジェクション(LDAP injection): 外部から受け取った値を LDAP の検索式に組み込むことで、意図しない検索を実行させる攻撃。kid の値をそのまま検索に使う実装で起こりうる。23章
SQL インジェクション(SQL injection): 外部から受け取った値を SQL 文に組み込むことで、意図しない問い合わせを実行させる攻撃。kid の値をそのまま鍵の検索に使う実装で起こりうる。23章
alg=none 攻撃(alg=none attack): JWT の alg を none に書き換え、署名を確かめない検証器に偽造トークンを受理させる攻撃。23章
アルゴリズム混同攻撃(algorithm confusion attack): RS256 などの公開鍵を検証に使う検証器に、alg を HS256 にしたトークンを渡し、公開鍵を HMAC の鍵として使わせて偽造トークンを受理させる攻撃。23章
kid インジェクション(kid injection): 鍵の検索に kid をそのまま使う検証器に、SQL 断片やファイルパスを入れた kid を渡し、検証鍵を攻撃者の知る値に変える攻撃。23章
CVE(Common Vulnerabilities and Exposures): 公開された脆弱性に一意の識別番号を付ける仕組み。23章
CVE-2022-21449(Psychic Signatures): Java 15〜18 の ECDSA 実装が署名値の範囲検査を欠き、r = s = 0 の署名を任意のメッセージと公開鍵に対して有効と判定した脆弱性。23章
形式解析(formal security analysis): プロトコルと攻撃者を数学的なモデルとして記述し、モデルの中でセキュリティ目標が常に成り立つことを証明する方法。25章
ブラウザ交換攻撃(browser-swapping attack): 攻撃者が自分のブラウザで開始したフローの認可 URL を被害者に開かせ、被害者のブラウザの認可レスポンスを自分のブラウザからクライアントに送る攻撃。認可レスポンスが漏れると防げない。25章
リスト型攻撃(credential stuffing): 他のサービスから漏洩したメールアドレスとパスワードの組を、別のサービスのログインに大量に試す攻撃。26章
XML 署名ラッピング(XML signature wrapping): 署名した要素と、アプリケーションが読む要素が異なる XML 文書を作り、署名の検証を通過させる攻撃。27章
トークンの中継(token passthrough): MCP サーバが、MCP クライアントから受け取ったアクセストークンを、そのまま上流の別の API に送ること。MCP の仕様が禁止している。27章

ブラウザとアプリ

カスタムURIスキーム(custom URI scheme): com.example.photo:/cb のように、ネイティブアプリが独自に OS へ登録する URI スキーム。同じスキームを複数のアプリが登録できる OS では、認可コードを悪意のあるアプリが受け取れる。9章
localStorage: ブラウザがオリジンごとに永続的に保存するキーと値の記憶領域。同じオリジンの JavaScript から読めるため、XSS が起きるとトークンを読み出される。15章
WebCrypto(Web Cryptography API): ブラウザが JavaScript に提供する暗号 API。鍵を抽出不可能として生成でき、その場合スクリプトからも秘密鍵の値を読み出せない。15章
CORS(Cross-Origin Resource Sharing): ページと異なるオリジンのサーバへJavaScriptからリクエストを送る制限を、サーバ側の許可に基づいて緩めるブラウザの仕組み。普及する前はブラウザ内からトークンエンドポイントを呼べなかった。19章
QRコード(QR code): URL などの文字列を2次元の図形として表す符号。クロスデバイスフローで、別の端末に認可の URL を渡す手段として使われる。20章
FIDO のクロスデバイス認証(FIDO Cross-Device Authentication、CDA): 別の端末のパスキーで認証する FIDO の方式。Bluetooth Low Energy で2つの端末が近くにあることを確かめるため、離れた場所からの誘導に強い。20章
サードパーティCookie(third-party cookie): ブラウザが表示中のサイトとは異なるサイトのCookie。iframe内のリクエストに付くCookieなど。追跡防止のため遮断するブラウザがあり、フロントチャネルログアウトとSession Managementが影響を受ける。21章
postMessage(postMessage API): 異なるオリジンのウィンドウやiframeの間で文字列を受け渡すブラウザのAPI。受け取る側は送信元のオリジンを検査する。21章
sessionStorage: ブラウザのタブごとに保存され、タブを閉じると消えるキーと値の記憶領域。localStorage と同じく JavaScript から読める。24章
IndexedDB: ブラウザ内の構造化データベース。WebCrypto の抽出不可能な鍵オブジェクトを保存できる。24章
Subresource Integrity(SRI): 外部から読み込むスクリプトのハッシュ値を HTML に書き、内容が一致しない場合は実行させないブラウザの仕組み。24章
IPv6: 128ビットのアドレスを使うインターネットプロトコルの版。ループバックアドレスは ::1。24章
SPA(single-page application): 最初に読み込んだ1つのページの中で JavaScript が画面を書き換え、サーバとは API 呼び出しだけでやり取りする Web アプリケーション。秘密を保持できないパブリッククライアント。24章
同一オリジンポリシー(same-origin policy): あるオリジンのスクリプトが別のオリジンのレスポンスを読むことを制限するブラウザの規則。24章
オリジン(origin): スキーム・ホスト名・ポートの組。ブラウザのセキュリティ境界の単位。24章
プリフライト(preflight): CORS で、カスタムヘッダを含む別オリジンへのリクエストの前にブラウザが送る OPTIONS リクエスト。許可がなければ本来のリクエストは送られない。24章
サイト(site): SameSite の判定単位。RFC 10017 は eTLD+1(公開サフィックスの1つ下までの登録可能なドメイン)として説明する。サブドメインどうしは別オリジンだが同一サイト。24章
XSS(cross-site scripting): 攻撃者が用意した文字列がページに埋め込まれ、スクリプトとして実行される脆弱性。実行されたコードは正規のコードと同じ権限を持つ。24章
CSP(Content Security Policy): ページが読み込み・実行してよいスクリプトなどのリソースを Content-Security-Policy ヘッダで制限する仕組み。24章
Host プレフィックス(__Host- prefix): 名前が __Host- で始まる Cookie に、Secure・セキュアなオリジン・Domain なし・Path=/ を課す規則。__Host-Http- はさらに HttpOnly と HTTP での設定を課す。24章
BFF(Backend for Frontend): サーバ側のコンポーネントが機密クライアントとして OAuth を担当し、トークンを Cookie のセッションに結びつけて保持し、リソースサーバへのリクエストを中継するアーキテクチャ。24章
トークン仲介バックエンド(token-mediating backend): サーバ側のコンポーネントが機密クライアントとしてトークンを取得し、アクセストークンだけをブラウザのアプリに渡すアーキテクチャ。24章
ブラウザ内 OAuth クライアント(browser-based OAuth client): ブラウザのアプリがパブリッククライアントとして OAuth のすべてを担当するアーキテクチャ。24章
ネイティブアプリ(native app): ユーザーが端末にインストールして実行するアプリケーション。配布物に秘密を埋め込めないため通常はパブリッククライアントとして扱うが、インスタンスごとに秘密を配布する場合は例外になる(RFC 8252 8.4節)。24章
外部ユーザーエージェント(external user-agent): アプリとは別のセキュリティ領域にあり、アプリが Cookie やページの内容にアクセスできないユーザーエージェント。典型は既定のブラウザ。24章
埋め込みユーザーエージェント(embedded user-agent): アプリの一部として動作し、アプリが Cookie やページの内容にアクセスできるユーザーエージェント。RFC 8252 は認可リクエストへの使用を禁止する。24章
WebView(web-view): アプリに埋め込んでアプリの制御下で Web ページを表示する部品。埋め込みユーザーエージェントの典型的な実装。24章
アプリ内ブラウザタブ(in-app browser tab): アプリの画面の中に表示されるが、ブラウザのセキュリティ特性と認証状態を保持するブラウザのタブ。24章
プライベートユース URI スキーム(private-use URI scheme): アプリが OS に登録する独自の URI スキーム。RFC 8252 は管理するドメイン名を逆順にした名前(com.example.app)を求める。24章
claimed https スキーム URI(claimed "https" scheme URI): ドメインの所有を証明したアプリが主張し、ブラウザの代わりにアプリが開く https の URI。宛先のアプリの同一性を OS が保証する。24章
Universal Links / App Links(Universal Links / App Links): claimed https スキーム URI を実現する機能の、Apple のプラットフォームと Android での名前。24章
ループバックリダイレクト(loopback redirect): アプリが 127.0.0.1 か [::1] で一時的に待ち受け、http://127.0.0.1:{port}/{path} で認可レスポンスを受け取る方法。認可サーバは任意のポートを許さなければならない。24章

拡張仕様

トークンイントロスペクション(token introspection): リソースサーバが認可サーバにトークンを送り、そのトークンが現在有効かと付随する情報を JSON で受け取る仕組み。RFC 7662 が定める。14章
イントロスペクションエンドポイント(introspection endpoint): トークンイントロスペクションのリクエストを受け付ける認可サーバのエンドポイント。呼び出し元の認可を必ず要求する。14章
active(active member): イントロスペクションの応答で、トークンが現在有効かを示す真偽値。唯一の必須メンバーで、無効の場合は理由を示さず false だけを返す。14章
token_type_hint(token type hint): イントロスペクションや失効のリクエストで、送ったトークンがアクセストークンかリフレッシュトークンかを伝える任意のヒント。14章
失効(revocation): 有効期限より前にトークンを無効にする操作。RFC 7009 は、クライアントが認可サーバに失効を要求する方法を定める。14章
失効エンドポイント(revocation endpoint): クライアントがトークンの失効を要求する認可サーバのエンドポイント。無効なトークンを送られた場合も 200 を返す。14章
audience(オーディエンス、宛先): トークンを受け入れるべき相手。JWT では aud クレームで表し、リソースサーバは自分が含まれないトークンを拒否する。14章
Resource Indicators(リソース指示子): クライアントが、トークンを使う先のリソースを resource パラメータで認可サーバに伝える仕組み。RFC 8707 が定める。14章
resource パラメータ(resource parameter): Resource Indicators で、要求するトークンの使用先を示す絶対 URI。フラグメントを含めてはならず、複数指定できる。14章
invalid_target(invalid target error): 要求された resource が不正、未知、または許可されないことを示すエラーコード。14章
Protected Resource Metadata(保護されたリソースのメタデータ): リソースサーバが、自分の識別子、利用できる認可サーバ、スコープなどを well-known URI で公開する仕組み。RFC 9728 が定める。14章
resource_metadata(resource metadata parameter): WWW-Authenticate ヘッダで、Protected Resource Metadata の URL をクライアントに示すパラメータ。14章
送信者制約トークン(sender-constrained token): 送信者制約が付いたトークン。使うたびに、結びつけられた鍵の所有証明を要求される。16章
送信者制約(sender-constraining): アクセストークンなどを使える送信者を特定のクライアントに限定すること。トークンを鍵に結びつけ、使うたびに所有証明を求める。16章
所有証明(proof of possession、PoP): ある鍵を持っていることを、その鍵による署名などで相手に示すこと。Bearer トークンの使用には不要で、送信者制約トークンの使用には必要。16章
cnf(confirmation): トークンを提示する者が持っているはずの鍵を表すクレーム。RFC 7800 が定め、中に jkt や x5t#S256 などを入れる。16章
DPoP(Demonstrating Proof of Possession): クライアントが生成した鍵で HTTP リクエストごとの JWT に署名し、アプリケーション層で所有を証明する送信者制約の仕組み。RFC 9449 が定める。16章
DPoP 証明(DPoP proof): DPoP ヘッダで送る、typ が dpop+jwt で公開鍵を jwk ヘッダに持つ JWT。jti、htm、htu、iat と、トークンと一緒なら ath を含む。16章
htm(HTTP method claim): DPoP 証明を付けた HTTP リクエストのメソッドを表すクレーム。16章
htu(HTTP target URI claim): DPoP 証明を付けた HTTP リクエストの対象 URI から、クエリとフラグメントを除いたものを表すクレーム。16章
ath(access token hash claim): アクセストークンの値の SHA-256 ハッシュを Base64url で符号化した値を表す DPoP 証明のクレーム。証明を特定のトークンに結びつける。16章
jkt(JWK SHA-256 Thumbprint confirmation method): cnf の中で、トークンを束縛した DPoP 公開鍵の JWK SHA-256 Thumbprint を Base64url で表すメンバー。16章
DPoP-Nonce(DPoP-Nonce ヘッダ): サーバが推測できない値をクライアントに渡し、次の DPoP 証明の nonce クレームに含めさせるための HTTP ヘッダ。事前に作られた証明を無効にする。16章
dpop_jkt(dpop_jkt parameter): 認可リクエストで DPoP 公開鍵の JWK Thumbprint を伝え、発行される認可コードをその鍵に束縛するパラメータ。16章
証明書束縛アクセストークン(certificate-bound access token): mTLS で使ったクライアント証明書に結びつけたアクセストークン。リソースサーバは同じ証明書による mTLS 接続でだけ受け入れる。RFC 8705 が定める。16章
x5t#S256(X.509 certificate SHA-256 thumbprint confirmation method): cnf の中で、X.509 証明書の DER 符号化の SHA-256 ハッシュを Base64url で表すメンバー。16章
PAR(Pushed Authorization Requests): クライアントが認可リクエストの内容を、クライアント認証を付けて認可サーバに直接送り、ブラウザには request_uri だけを通す仕組み。RFC 9126 が定める。17章
PAR エンドポイント(pushed authorization request endpoint): PAR のリクエストを受け付け、201 で request_uri と expires_in を返す認可サーバのエンドポイント。17章
request_uri(request URI parameter): 認可リクエストの内容(リクエストオブジェクトや PAR で送った内容)を参照する値を認可エンドポイントに渡すパラメータ。PAR では1回限りでクライアントに束縛される。17章
JAR(JWT-Secured Authorization Request): 認可リクエストのパラメータを署名付きの JWT に入れて送る仕組み。RFC 9101 が定める。17章
リクエストオブジェクト(request object): JAR で、認可リクエストのすべてのパラメータをクレームとして持つ、署名(と任意で暗号化)された JWT。認可サーバはこの中のパラメータだけを使う。17章
request パラメータ(request parameter): リクエストオブジェクトを値として認可エンドポイントに渡すパラメータ。request_uri と同時には使えない。17章
RAR(Rich Authorization Requests): 認可の要求を JSON の構造で表し、スコープでは表せない具体的な権限を要求する仕組み。RFC 9396 が定める。17章
authorization_details(authorization details parameter): RAR で、type フィールドを必須とするオブジェクトの JSON 配列として認可の要求を表すパラメータ。17章
iss パラメータ(iss parameter): 認可レスポンスに認可サーバの issuer 識別子を入れるパラメータ。クライアントは送り先の issuer と単純な文字列比較で照合する。RFC 9207 が定める。17章
response_mode(response mode parameter): 認可レスポンスのパラメータを返す方法(query、fragment、form_post など)を認可サーバに指示するパラメータ。17章
form_post(form post response mode): 認可レスポンスのパラメータを HTML フォームの隠しフィールドに入れ、ブラウザに自動送信させてクライアントへ POST で届ける response_mode の値。17章
JARM(JWT Secured Authorization Response Mode): 認可レスポンスのパラメータを、iss、aud、exp とともに認可サーバが署名した JWT に入れて返す方法。17章
unmet_authentication_requirements(unmet_authentication_requirements error): OPが要求された認証の条件を満たせなかったことを示すエラーコード。RFC 9470は、要求された acr を満たせないときにアクセストークンの発行を失敗させ、このエラーを返すべきとする。OpenID Connect Unmet Authentication Requirements 1.0。18章
ステップアップ認証(step-up authentication): 操作の重要度に応じて、より強い認証やより新しい認証を途中から要求すること。リソースサーバからの要求方法はRFC 9470が定める。18章
insufficient_user_authentication(insufficient_user_authentication error): アクセストークンに対応する認証が、保護されたリソースの要求を満たしていないことを示すエラーコード。WWW-Authenticateヘッダのacr_valuesとmax_ageで条件を伝える。RFC 9470。18章
Multiple Response Type(multiple-valued response type): code、token、id_tokenなどの値を空白区切りで組み合わせたresponse_type。値の集合として比較し、順序は意味を持たない。OAuth 2.0 Multiple Response Type Encoding Practicesが定める。19章
response_mode=fragment(fragment response mode): 認可応答のパラメータをリダイレクトURIのフラグメントに入れて返す応答モード。code以外を含むresponse_typeの既定。19章
STS(security token service): トークンを受け取り、別の宛先や形式のトークンを発行するサービス。RFC 8693 のトークン交換はこのサービスへの要求の形式を定める。20章
JWTベアラーグラント(JWT bearer grant): 信頼できる発行者が署名したJWTをassertionパラメータで提示してアクセストークンを得るグラント。RFC 7523 2.1節。20章
デバイス認可グラント(device authorization grant): 入力手段の少ない端末が、利用者に別の端末のブラウザで認可してもらい、ポーリングでアクセストークンを得るグラント。RFC 8628。20章
device_code(device_code parameter): デバイス認可グラントで端末がトークンリクエストに使う検証コード。利用者には見せず、高いエントロピーにする。20章
user_code(user_code parameter): デバイス認可グラントで利用者が別の端末に入力する短いコード。総当たりを防ぐために試行回数を制限する。20章
verification_uri(verification_uri parameter): デバイス認可グラントで利用者がブラウザで開く認可サーバのURI。20章
ポーリング(polling): 状態が変わったかを一定間隔で問い合わせ続ける方式。デバイス認可グラントやCIBAのPollモードで、クライアントがトークンエンドポイントに対して行う。20章
authorization_pending(authorization_pending error): 利用者がまだ操作を終えていないことを示すトークンエンドポイントのエラー。クライアントはinterval秒以上待って問い合わせを繰り返す。20章
slow_down(slow_down error): ポーリングが速すぎることを示すトークンエンドポイントのエラー。クライアントは以降の間隔を5秒延ばす。20章
トークン交換(token exchange): 手元のトークンを認可サーバ(STS)に提示し、別の宛先や形式のトークンと交換するグラント。RFC 8693。20章
なりすまし(impersonation): トークン交換の意味づけの1つ。行動する主体が、定められた範囲で元の主体の権限をすべて持ち、受け取る側から区別できない。20章
委任(delegation): トークン交換の意味づけの1つ。行動する主体が自分の識別子を保ったまま元の主体を代表して行動し、トークンに両者が記録される。20章
subject_token(subject_token parameter): トークン交換で、誰のためにリクエストしているかを表すトークン。20章
actor_token(actor_token parameter): トークン交換で、行動する主体を表すトークン。委任のときに使う。20章
act クレーム(actor claim): 委任が行われたことと現在のアクターをJWTの中で表すクレーム。入れ子で連鎖を表し、アクセス制御には最も外側だけを使う。RFC 8693 4.1節。20章
may_act クレーム(authorized actor claim): そのトークンの主体を代表して行動してよい主体を記すクレーム。RFC 8693 4.4節。20章
CIBA(Client-Initiated Backchannel Authentication): RPがブラウザのリダイレクトを使わず、利用者の識別子をもとにOPへ直接認証を依頼し、Poll、Ping、Pushのいずれかで結果を受け取るフロー。OpenID Foundation CIBA Core 1.0。20章
消費デバイス(consumption device): CIBAなどで、利用者がサービスを使う端末。利用者自身が操作するとは限らない。20章
認証デバイス(authentication device): CIBAで、利用者が認証と同意を行う端末。多くはスマートフォン。20章
binding_message(binding_message parameter): CIBAで消費デバイスと認証デバイスの両方に表示する短い文字列。利用者が2つの操作の対応を確かめるために使う。20章
auth_req_id(auth_req_id parameter): CIBAの認証リクエストを識別する値。最低128ビットのエントロピーを持つ。20章
クロスデバイスフロー(cross-device flow): 利用者が1つの端末で始めた操作を別の端末で完了させるフロー。デバイス認可グラントやCIBA。RFC 10027(BCP 247)。20章
セキュリティプロファイル(security profile): 基盤となる仕様の選択肢を限定し、推奨を必須に変えた要件の集合。準拠した実装どうしは交渉なしに接続でき、安全性を1つの構成について分析できる。25章
OAuth 2.1(OAuth 2.1): RFC 6749 と RFC 7636・8252・9700 などを統合し、インプリシット・ROPC・plain などを削除した OAuth の改訂版。2026年10月時点で Internet-Draft(draft-ietf-oauth-v2-1-16)。25章
FAPI 2.0(FAPI 2.0): OpenID Foundation が定める、高い価値を持つ API を保護するための OAuth 2.0 のセキュリティプロファイル。Attacker Model・Security Profile・Message Signing からなる。25章
FAPI 2.0 Message Signing(FAPI 2.0 Message Signing): JAR・JARM・署名付きイントロスペクション・ID トークンの署名で、FAPI 2.0 のメッセージに否認防止を加えるプロファイル。25章
オープンバンキング(open banking): 銀行が口座情報や送金の機能を API として公開し、顧客の同意に基づいて第三者の事業者が利用できるようにする仕組み。FAPI の主な用途。25章

運用と周辺技術

HashMap: Rust 標準ライブラリのハッシュ表。キーから値を平均して一定時間で検索できる。本書の実験ではセッションストアや認可コードの保存先として使う。1章
データベース(database): アプリケーションのデータを永続的に保存し、検索・更新する仕組み。2章
クロックスキュー(clock skew): 発行者と検証者の時計のずれ。exp や iat の判定で、期限内のトークンを拒否したり期限切れのトークンを受け入れたりする原因になる。8章
leeway: クロックスキューを吸収するために、exp・nbf・iat の判定に設ける小さな猶予。通常は数分以内にする。8章
Cargo: Rust のビルドツール兼パッケージマネージャ。依存クレートの取得、ビルド、実行を行う。10章
async: Rust の非同期処理の構文。I/O の完了を待つ間にスレッドを他の処理に使えるようにする。本書の examples は tokio の上で async の関数として書いている。10章
鍵ローテーション(key rotation): 署名鍵を新しい鍵に切り替える運用。新しい鍵を JWKS に追加し、署名を切り替え、古い鍵で署名したトークンが失効してから古い鍵を JWKS から削除する。10章
ロードバランサ(load balancer): 受け取ったリクエストを複数のサーバに振り分ける装置やソフトウェア。TLS を終端する場合、mTLS のクライアント証明書をアプリケーションに渡す方法が問題になる。13章
UUID(universally unique identifier): 128ビットの識別子。バージョン4は乱数から作られ、jti のような一意な値に使われる。16章
CRIME/BREACH: TLS や HTTP の圧縮を利用して、暗号化された通信に含まれる秘密の値(Cookie やトークン)を少しずつ推定する攻撃。16章
Cloudbleed: 2017年に公表された、CDN のパーサの誤りにより他の利用者の通信内容がレスポンスに混入した事故。トークンが予期しない経路で漏洩する例。16章
SMS(short message service): 携帯電話の番号宛てに短い文字列を送る仕組み。ワンタイムコードの送付に使われるが、番号の乗っ取りなどの弱点がある。18章
自己認定(self-certification): 実装者が OpenID Foundation の適合性テストを自分で実行し、結果と適合の宣言を提出する認定の方式。第三者の監査による確認ではない。26章
鍵の退役(key retirement): ローテーションで使わなくなった署名鍵を JWK Set から削除し、署名にも検証にも使わない状態にすること。旧鍵で署名した最後のトークンの寿命が切れてから行う。26章
HSM(hardware security module): 秘密鍵を装置の外に出さずに署名などの暗号処理を行う専用の装置。サーバが侵害されても秘密鍵そのものは複製されない。26章
緊急ローテーション(emergency rotation): 鍵の漏洩を理由に、キャッシュ期間やトークンの寿命の待ち時間を置かずに新しい鍵へ切り替え、漏洩した鍵を直ちに削除するローテーション。有効なトークンが一斉に検証できなくなる。26章
レート制限(rate limiting): 一定時間あたりに許可する処理の回数に上限を設け、超えた分を拒否または遅延させる制御。未知の kid による JWKS 再取得やトークンエンドポイントに適用する。26章
NTP(Network Time Protocol): ネットワーク上の時刻サーバと通信して、OS の時計を一定の誤差内に保つプロトコル。exp や iat の判定の前提となる。26章
マルチテナント(multi-tenant): 1つのサービスの実体で、互いに独立した複数の利用組織を収容する構成。マルチテナント OP はテナントごとに異なる issuer を使うことがある。26章
テナント(tenant): マルチテナントのサービスに収容される個々の利用組織。ユーザーのディレクトリや管理者がテナントごとに分かれる。26章
SaaS(software as a service): 利用者が自分で導入せずに、インターネット経由で提供される業務用のソフトウェアサービス。26章
監査ログ(audit log): ログイン、同意、トークンの発行と失効、設定変更など、誰がいつ何をしたかを後から証明するための記録。通常のログと分け、改ざんできない保存先に保存する。26章
インシデント対応(incident response): セキュリティ上の事故を検知してから、被害の拡大を止め、原因を取り除き、通常の運用に戻すまでの一連の手順。26章
Web PKI: ブラウザが信頼する認証局と、そこから発行されたサーバ証明書で構成される、HTTPS の公開鍵基盤。27章
rpIdHash: WebAuthn の認証器データに含まれる、RP ID の SHA-256 ハッシュ。サーバは期待する RP ID のハッシュと一致することを確認する。27章
UP フラグ(user present flag): WebAuthn の認証器データのフラグのうち、認証器がユーザーの在席を確認したことを示すビット。27章
UV フラグ(user verified flag): WebAuthn の認証器データのフラグのうち、認証器が PIN や生体情報でユーザー本人を確認したことを示すビット。27章
SAML(Security Assertion Markup Language): XML で書かれた認証結果を IdP から SP に渡すための OASIS の仕様。SAML 2.0 は2005年3月に OASIS 標準になった。27章
SP(service provider): SAML で認証結果を受け取るサービス。OIDC の RP に相当する。27章
SAML アサーション(SAML assertion): SAML で認証結果を表す XML 文書。アサーション自体か、それを含む Response 要素に XML 署名を付けて保護する。27章
プロビジョニング(provisioning): ID 管理の元となるシステムから、各サービスにユーザーのアカウントを作成・更新・削除して反映する処理。27章
SCIM(System for Cross-domain Identity Management): プロビジョニングを HTTP と JSON で行うための IETF の標準。RFC 7643(スキーマ)と RFC 7644(プロトコル)、2015年9月。27章
WebAuthn(Web Authentication): ブラウザの JavaScript API を通じて、公開鍵暗号によるユーザー認証を行う W3C の仕様。Level 3 は2026年8月に W3C 勧告になった。27章
認証器(authenticator): WebAuthn で、サービスごとに鍵ペアを生成して秘密鍵を保持し、ログイン時に署名する装置またはソフトウェア。27章
FIDO2: WebAuthn と CTAP を合わせた、FIDO Alliance と W3C の仕様群の総称。27章
CTAP(Client to Authenticator Protocol): 外付けのセキュリティキーなどの認証器と、ブラウザまたは OS の間の通信プロトコル。27章
パスキー(passkey): WebAuthn の資格情報のうち、ユーザー名の入力なしに選択でき、多くの場合は端末間で同期される資格情報。27章
RP ID(relying party identifier): WebAuthn で鍵を登録したサービスを識別するドメイン名。スキームとポートを含まない点でオリジンとは異なる単位で、ブラウザはページのオリジンのドメインが RP ID と等しいかその下位のドメインである場合にだけ署名させる。OIDC の RP とは別の概念。27章
OpenID Federation: 信頼できる第三者(トラストアンカー)を介して、事前の個別登録なしに OP と RP の信頼を確立する OpenID Foundation の仕様。1.0 は2026年2月、1.1 は2026年5月に最終版。27章
エンティティ識別子(Entity Identifier): OpenID Federation でエンティティを識別する、https のスキームとホストを持ち、クエリとフラグメントを含まない URL。27章
トラストアンカー(Trust Anchor): OpenID Federation で信頼の起点となるエンティティ。検証する側はその公開鍵を事前に別の手段で受け取る。27章
中間エンティティ(Intermediate Entity): トラストアンカーとリーフエンティティの間にあるエンティティ。組織などが該当する。27章
リーフエンティティ(Leaf Entity): 配下を持たない末端のエンティティ。通常は OP や RP。27章
エンティティステートメント(Entity Statement): OpenID Federation で信頼の情報を表す署名付きの JWT。typ は entity-statement+jwt。27章
エンティティ設定(Entity Configuration): エンティティが自分自身について発行するエンティティステートメント。iss と sub が同じで、/.well-known/openid-federation で公開する。27章
下位ステートメント(Subordinate Statement): 上位のエンティティが直下のエンティティについて発行するエンティティステートメント。直下のエンティティの鍵を保証する。27章
authority_hints: エンティティ設定に含める、直上のエンティティの識別子の配列。検証する側はこれを辿ってトラストアンカーに到達する。27章
トラストチェーン(Trust Chain): 検証対象のエンティティ設定から始まり、下位ステートメントを順に辿って、トラストアンカーのエンティティ設定で終わるエンティティステートメントの列。27章
メタデータポリシー(metadata policy): 上位のエンティティが下位ステートメントに書く、配下のエンティティのメタデータの値を制限・上書きする規則。下位の組織は緩められない。27章
トラストマーク(Trust Mark): 第三者が、エンティティが特定の要件に適合していることを証明する署名付きの JWT。27章
検証可能クレデンシャル(verifiable credential): 発行者が利用者についての情報を記載して署名し、利用者が保持して必要な相手に提示できるデジタルの資格情報。27章
ウォレット(wallet): 検証可能クレデンシャルを保持し、提示を管理するソフトウェア。多くの場合スマートフォンのアプリ。27章
SD-JWT VC: SD-JWT を検証可能クレデンシャルの形式として使うための IETF の仕様。typ に dc+sd-jwt を使う。2026-10-16 時点で draft-ietf-oauth-sd-jwt-vc-19。27章
vct(vct クレーム): SD-JWT VC で、クレデンシャルの種類を表す識別子のクレーム。27章
mdoc: ISO/IEC 18013-5 が定める、モバイル運転免許証などのクレデンシャルの形式。27章
OpenID4VCI(OpenID for Verifiable Credential Issuance): 発行者がウォレットにクレデンシャルを発行する手順を OAuth の形で定める仕様。1.0 は2025年9月に最終版。27章
Pre-Authorized Code フロー(pre-authorized code flow): OpenID4VCI で、発行者が別の手段で利用者を確認した後に渡したコードを、ウォレットがアクセストークンと交換する方式。27章
OpenID4VP(OpenID for Verifiable Presentations): 検証者がウォレットにクレデンシャルの提示を要求し、ウォレットが提示を返す手順を OAuth の形で定める仕様。1.0 は2025年7月に最終版。27章
Digital Credentials API: Web ページがブラウザと OS を通じてウォレットにクレデンシャルの提示を要求するための W3C の API。27章
AI エージェント(AI agent): 大規模言語モデルを使い、利用者の指示に従って外部のツールを呼び出しながら処理を進めるアプリケーション。27章
MCP(Model Context Protocol): AI エージェントが外部のツールやデータにアクセスするための通信プロトコル。HTTP での認可は OAuth 2.1、RFC 9728、RFC 8707 などを組み合わせて定める。27章
MCP クライアント(MCP client): MCP で、ツールを利用する AI エージェント側。認可では OAuth のクライアントになる。27章
MCP サーバ(MCP server): MCP で、ツールやデータを提供する側。認可では OAuth のリソースサーバになる。27章

標準化

Rust Playground: Rust のコードをブラウザから送って、サーバ上でコンパイル・実行できる公式のサービス。本書の RustPlay の実行先。1章
RFC(Request for Comments): インターネットの技術仕様を収めた、通し番号付きの文書。発行後に本文は変更されない。1章
IETF(Internet Engineering Task Force): インターネットのプロトコルを標準化する団体。ワーキンググループでの合意によりRFCを作成する。1章
廃止(Obsoletes)/更新(Updates): 新しいRFCが古いRFCを置き換える、または部分的に変更する関係。RFCの冒頭に記される。1章
Standards Track: 標準化の過程にあるRFCの種別。1章
BCP(Best Current Practice): 現時点で最善とされる運用上の指針を示すRFCの種別。1章
Informational: 情報提供のためのRFCの種別。標準ではない。1章
要請語(requirement keywords): RFCで要件の強さを示す大文字の語(MUST、SHOULD、MAYなど)。意味はBCP 14(RFC 2119とRFC 8174)が定める。1章
Internet-Draft: RFCになる前のIETFの作業文書。版番号が付き、内容は版ごとに変わりうる。標準ではない。2章
ABNF(Augmented Backus-Naur Form): RFCで構文を定義するための記法。4章
OpenID Foundation(OIDF): OpenID Connect をはじめとする OpenID 関連の仕様を策定する非営利団体。6章
MTI(mandatory to implement): 仕様に適合する実装が必ず備えなければならない機能。PKCE では S256 が MTI。9章
型状態パターン(typestate pattern): 値の状態を型引数で表し、状態ごとに呼べるメソッドを変える設計。openidconnect 4 はエンドポイントの設定状態を EndpointSet / EndpointNotSet / EndpointMaybeSet で表す。11章
適合性テスト(conformance testing): 実装が仕様の要件どおりに動作するかを、定められたテストケースを実装に対して実行して確かめること。25章
OpenID 認定(OpenID Certification): 実装者が適合性テストを自分で実行し、結果と適合の宣言を OpenID Foundation に提出して、認定済みの実装の一覧に掲載される制度。第三者による監査ではなく自己認定である。25章
提案標準(Proposed Standard): 標準化過程(Standards Track)の RFC が最初に置かれる段階。OAuth 2.0 や PKCE の RFC もこの段階のまま広く実装されている。付録 RFCの読み方
IESG(Internet Engineering Steering Group): IETF の文書を RFC として発行する前に審査・承認する組織。付録 RFCの読み方
RFC Editor: RFC の編集と発行を担当する組織。RFC ごとの情報ページで正誤表や更新関係を公開している。付録 RFCの読み方
IETF Datatracker: IETF の文書(Internet-Draft と RFC)の版の履歴と状態を公開しているサイト。付録 RFCの読み方
Security Considerations(セキュリティ上の考慮事項): すべての RFC に置かれる、セキュリティ上の考慮事項を書く節。OAuth/OIDC では攻撃と対策が具体的に書かれている。付録 RFCの読み方
テストベクタ(test vector): 仕様が定める計算の入力と、期待される出力の組。実装が仕様どおりに計算しているかの検証に使う。付録 RFCの読み方
正誤表(errata): RFC の発行後に報告された誤りの記録。検証済み(Verified)の正誤表は本文の訂正として扱う。付録 RFCの読み方
レジストリ(registry): IANA が管理する、プロトコルで使う名前や番号の一覧。OAuth Parameters、JSON Web Token Claims、JOSE などがある。付録 RFCの読み方
Implementer's Draft(実装者向けドラフト): OpenID Foundation の仕様で、実装を始めてよい段階として承認された版。付録 RFCの読み方
Final(最終仕様): OpenID Foundation の会員投票で承認された、確定版の仕様。付録 RFCの読み方
正誤表セット(errata set): OpenID 仕様で、報告された誤りの訂正をまとめて取り込んだ版。OpenID Connect Core 1.0 の現行版は errata set 2 を取り込んだもの。付録 RFCの読み方