OAuth／OIDC × Agent

Agent systems mix human login, delegated user access, workload identity, and service-to-service calls. Future updates must not call authentication, authorization, identity claims, and delegated agent authority the same thing.

identity / governance / security / interoperability / Enterprise AI Core / provider mapping

What do OAuth 2.0, OIDC Core, RFC 9700, and PKCE establish for access and end-user identity, and what agent-specific identity/delegation questions remain open?

[S1] SOURCE_CLASS: standards_track_rfc | EXACT_TITLE: RFC 6749 - The OAuth 2.0 Authorization Framework | AUTHOR_ORG: IETF / RFC Editor; Dick Hardt (editor) | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc6749.html | PUBLICATION_UPDATE_ACCESS: October 2012; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: RFC 6749 | SUPPORTING_LOCATOR: abstract and authorization framework sections describing a third-party application obtaining limited access to an HTTP service | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for OAuth authorization framework; limit because OAuth does not itself provide an end-user identity profile. [S2] SOURCE_CLASS: identity_standard | EXACT_TITLE: OpenID Connect Core 1.0 incorporating errata set 2 | AUTHOR_ORG: OpenID Foundation | CANONICAL_URL: https://openid.net/specs/openid-connect-core-1_0.html | PUBLICATION_UPDATE_ACCESS: current errata-set-2 page; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: OpenID Connect Core 1.0 errata set 2 | SUPPORTING_LOCATOR: abstract lines 16-18; introduction lines 212-217; claims section lines 1548-1566 in the recorded web capture | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for identity layer, authentication, and claims; limit for the distinction from access authorization. [S3] SOURCE_CLASS: best_current_practice_rfc | EXACT_TITLE: RFC 9700 - Best Current Practice for OAuth 2.0 Security | AUTHOR_ORG: IETF / RFC Editor | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc9700.html | PUBLICATION_UPDATE_ACCESS: 2025-01; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: RFC 9700 | SUPPORTING_LOCATOR: authorization-code binding and PKCE lines 576-586; refresh-token protection lines 774-790 | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for current security recommendations; limit because BCP recommendations require deployment enforcement. [S4] SOURCE_CLASS: standards_track_rfc | EXACT_TITLE: RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients | AUTHOR_ORG: IETF / RFC Editor; Nat Sakimura et al. | CANONICAL_URL: https://www.rfc-editor.org/rfc/rfc7636.html | PUBLICATION_UPDATE_ACCESS: September 2015; accessed 2026-09-14 00:10 JST | VERSION_RELEASE_TAG: RFC 7636 | SUPPORTING_LOCATOR: abstract lines 9-17 and introduction lines 108-113 describing authorization-code interception and PKCE mitigation | EVIDENCE_LABEL: VERIFIED_SPEC | RELATION: support for PKCE threat/countermeasure; limit because PKCE does not solve all token/delegation problems.

• ESTABLISHED [S1 support]: OAuth 2.0 is an authorization framework in which a third-party application can obtain limited access to an HTTP service. It is about access delegation, not a complete statement that the caller is a human, agent, or trusted workload.
• ESTABLISHED [S2 support]: OIDC Core is an identity layer on OAuth 2.0. It enables a client to verify the End-User identity based on authorization-server authentication and obtain claims; the introduction explicitly notes that OAuth 2.0 alone does not define standard end-user identity information.
• ESTABLISHED [S3+S4 support]: RFC 9700 describes binding authorization codes to the client/device context and identifies PKCE as a countermeasure; RFC 7636 defines the authorization-code interception threat and PKCE technique. RFC 9700 also requires risk-based refresh-token decisions and scope/resource binding when refresh tokens are issued.
• INFERENCE [S1-S4]: Applying these standards to an agent architecture requires an explicit mapping between human identity, workload/service identity, delegated authority, resource/audience, scopes, agent run, and tool action. The base sources do not, by themselves, define an agent's intent, autonomy, chain of delegation, or business approval semantics.

OAuth/OIDC success does not prove least privilege, user intent, agent identity, tool authorization, correct audience, tenant isolation, or safe downstream action. Bearer/refresh-token leakage, confused deputy, over-broad scope, issuer mix-up, redirect/PKCE errors, stale claims, replay, token exchange, and service-account misuse remain deployment risks. RFC 9700 is a BCP, not an automatically enforced control. No provider or tenant implementation was tested.

issuer/discovery and TLS; client registration/type; authorization-code flow; PKCE enforcement; redirect URI; state/nonce; token issuer/audience/resource; scopes and consent; access/refresh lifetime and rotation/revocation; OIDC claims and verification; workload/service identity; token exchange/delegation profile; tenant/admin policy; region/plan; secret/key storage; audit and attribution.

Evidence-only desk research. No authorization request, token exchange, login, service-account operation, or authenticated tenant action was performed.

No identity-provider interoperability, PKCE negative test, token replay, scope/audience, delegation-chain, revocation, or audit-attribution benchmark was run.

Verify issuer, signature, nonce/state, PKCE, audience/resource, scope, expiry, revocation/rotation, and tenant binding before tool execution. Never place tokens in prompts or ordinary logs. Audit should link subject/client/workload/agent-run/delegation-chain/tool-action/approval; base RFCs do not guarantee that linkage. Cost/operability includes authorization round trips, token refresh, introspection/revocation, key rotation, policy evaluation, and human approval; not measured.

「OAuth 2.0は限定的なHTTPリソースアクセスの委任、OIDCはOAuth上でEnd-Userの認証結果とclaimsを扱うidentity layerである。Agent運用では、human／workload／service identity、resource/audience、scope、delegation chain、tool action、approvalを別々に結び付ける必要があり、OAuth／OIDCの成功だけではagentの権限・意図・安全な実行を証明しない。」

Future update Work should pin RFC/OIDC references and build a provider-neutral identity TEST_PROFILE: authorization-code+PKCE, state/nonce, audience/resource restriction, least-privilege scopes, token expiry/rotation/revocation, delegated human-to-agent-to-tool attribution, confused-deputy negative case, service identity, tenant offboarding, and audit readback. Add provider-specific availability only after current docs and non-authenticated documentation are re-checked.

agent identity/delegation standard; token-exchange and resource-indicator profile for agents; non-human identity semantics; provider/tenant scope mapping; card/run/tool attribution; dynamic registration; sender-constrained tokens; revocation propagation; incident rates; audit/cost/SLO.

Do not treat OAuth as identity, OIDC as authorization, a valid token as proof of user intent, or a successful login as proof of agent/tool authority. Do not claim RFC 9700/PKCE enforcement without testing the actual authorization server configuration. UNIT_CLOSE_STATUS: INDIVIDUAL_BOUNDED_CLOSE / EVIDENCE_RECORDED / UNKNOWN_PRESERVED

===== RUN CLOSE / HANDOFF ===== INDIVIDUAL_PACKET_COUNT: 6/6 (EA-157..EA-162)

MCP dated specification and release boundary; A2A latest plus v0.3.0 fixed specification and author repository; AG-UI official docs/events draft and repository; OpenAPI 3.1.0 and OpenAI function-calling docs; CloudEvents v1.0.2 core/binding; OAuth RFC 6749, OIDC Core 1.0 errata set 2, RFC 9700, and RFC 7636. Canonical URLs and locators are recorded per packet.

Six EA_IDs each have independent exact topic, evidence table, findings, limits/counterevidence/failure envelope, gates, implementation state, benchmark boundary, security/cost/operability notes, safe wording, handoff, unknowns, and stop condition. Shared sources are not treated as shared claims.

Official specifications establish the documented contract at the recorded version/access boundary. They do not prove a particular plan, region, tenant, implementation, conformance, quality, security posture, business outcome, or SLO. LIVE_SIDE_EFFECTS: 0