# OAuth／OIDC × Agent

CURRENT_STATUS: UNKNOWN
OBSERVATION: SPEC_ONLY
FRESHNESS: UNKNOWN
PAGE_TYPE: reference
CANONICAL_URL: /tools/ea-162-oauth-oidc-agent
CLAIM_IDS: none
EVIDENCE_IDS: EVD-EA-162-URL-36F1B4622524, EVD-EA-162-URL-CFD2790A544C, EVD-EA-162-URL-4E6D674BF887, EVD-EA-162-URL-CB6A61ADD96B, EA-162-R11-RESEARCH, EA-162-R11-WEB-READBACK
UNKNOWN_IDS: EA-162-UNKNOWN-01, EA-162-UNKNOWN-CURRENTNESS
OPS_IDS: none

## Summary
「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の権限・意図・安全な実行を証明しない。」

## Current judgment
1. 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.
2. 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.
3. 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.
4. 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.

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

## Confirmed
- 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.

## UNKNOWN
- EA-162-UNKNOWN-01: 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.
- EA-162-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。

## Evidence
- EVD-EA-162-URL-36F1B4622524 (RESEARCH): The OAuth 2.0 Authorization Framework | AUTHOR_ORG: IETF / RFC Editor; Dick Hardt (editor) | CANONICAL_URL: — https://www.rfc-editor.org/rfc/rfc6749.html
- EVD-EA-162-URL-CFD2790A544C (RESEARCH): [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
- EVD-EA-162-URL-4E6D674BF887 (RESEARCH): Best Current Practice for OAuth 2.0 Security | AUTHOR_ORG: IETF / RFC Editor | CANONICAL_URL: — https://www.rfc-editor.org/rfc/rfc9700.html
- EVD-EA-162-URL-CB6A61ADD96B (RESEARCH): 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
- EA-162-R11-RESEARCH (RESEARCH): EA-162 監査済みresearch / canonical revision binding
- EA-162-R11-WEB-READBACK (IMPL): EA-162 Web body identity / canonical readback

## Failure / limits
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.
## Failure / limits
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)
## Practice
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.
## Practice
Evidence-only desk research. No authorization request, token exchange, login, service-account operation, or authenticated tenant action was performed.
## Practice
No identity-provider interoperability, PKCE negative test, token replay, scope/audience, delegation-chain, revocation, or audit-attribution benchmark was run.
## Practice
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.
## Practice
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.
## Practice
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.
## WHY_THIS_MATTERS_TO_UPDATE
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.

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

## CLAIM_OR_RESEARCH_QUESTION
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?

## EVIDENCE_TABLE
[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.

## FINDINGS
1. 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.
2. 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.
3. 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.
4. 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.

## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE
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.

## AVAILABILITY_GATES
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.

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

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

## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY
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.

## SAFE_WORDING_FOR_FUTURE_BOOK
「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の権限・意図・安全な実行を証明しない。」

## UPDATE_WORK_HANDOFF
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.

## OPEN_UNKNOWN
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.

## STOP_CONDITION
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)

## PRIMARY_SOURCE_RECORD
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.

## CLAIM_SEPARATION
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.

## EVIDENCE_BOUNDARY
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

NEXT: /agent/start.json
STOP: This is a knowledge projection, not an execution order.