SW-A2A-005: OAuth implicit or password flow declared (deprecated in A2A 1.0)

What it detects

The rule goes through the card's security schemes. For every OAuth 2 scheme, in the 1.0 shape (oauth2SecurityScheme) or the 0.x shape (type oauth2), it reads the flows member and reports each flow named implicit or password, at the flow's pointer, for example /securitySchemes/oauth/oauth2SecurityScheme/flows/implicit. The other flows (authorizationCode, clientCredentials and deviceCode) are not reported by this rule.

A2A 1.0 deprecates the two flows and documents them as removed, but the protocol's proto file still carries them as deprecated fields. So a card that declares one is not invalid, and the scanner reports it as a finding, not as a parse error. A card with such a flow also gets a migration status and a checklist in the report.

Why it matters

The implicit flow returns the access token in the address the browser is sent back to, where it can be copied from history, logs and the Referer header. The password flow hands the user's own password to the client, which defeats the point of delegating access. The OAuth 2.0 security best current practice (RFC 9700) says clients should not use the implicit grant and that the password grant must not be used. The scanner maps this rule to OWASP ASI03, Identity and Privilege Abuse, and to NIST SP 800-53 control IA-5, Authenticator Management.

Example

A complete card whose OAuth 2 scheme declares the implicit flow:

.well-known/agent-card.json

{
  "name": "demo-agent",
  "description": "Drafts release notes from merged pull requests.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://agent.example.invalid/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": {},
  "securitySchemes": {
    "oauth": {
      "oauth2SecurityScheme": {
        "flows": {
          "implicit": {
            "authorizationUrl": "https://auth.example.invalid/authorize",
            "scopes": {
              "notes.read": "Read release notes"
            }
          }
        }
      }
    }
  },
  "securityRequirements": [
    {
      "schemes": {
        "oauth": {
          "list": [
            "notes.read"
          ]
        }
      }
    }
  ],
  "defaultInputModes": [
    "text/plain"
  ],
  "defaultOutputModes": [
    "text/plain"
  ],
  "skills": [
    {
      "id": "release-notes",
      "name": "Release notes",
      "description": "Drafts release notes for one tag.",
      "tags": [
        "release"
      ]
    }
  ]
}

The finding points at the implicit member of the flows and says the flow is deprecated in A2A 1.0.

How to fix

Replace the flow. Use authorizationCode with pkceRequired set to true for a person who signs in, clientCredentials for one service that calls another, or deviceCode for a device without a browser. Change the client registration at the identity provider to match and switch the old flow off there, so a token can no longer be issued that way.

If it is a false positive

The finding is about what the card declares, not about what the identity provider allows. If the flow is already switched off at the provider, update the card anyway so it says what is true. If the agent is being retired and you cannot change the card yet, accept the finding with a note that names the date the flow ends.

If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.

Related rules

• SW-A2A-006: OAuth authorization code flow without PKCE required
• SW-A2A-007: Agent declares no authentication