[
  {
    "type": "authorization_code",
    "name": "Authorization Code",
    "description": "The client redirects the user to the authorization server, which returns an authorization code that the client exchanges for an access token. The most secure and widely recommended grant type for server-side web applications.",
    "spec": "RFC 6749 §4.1",
    "requires_client_secret": true,
    "requires_user_interaction": true,
    "token_endpoint_auth": true,
    "status": "active",
    "notes": "Should be used with PKCE (RFC 7636) to protect against authorization code interception attacks."
  },
  {
    "type": "authorization_code_with_pkce",
    "name": "Authorization Code with PKCE",
    "description": "Extension of the Authorization Code grant that uses a dynamically generated code verifier and code challenge to prevent authorization code interception attacks. Recommended for public clients such as single-page apps and mobile apps.",
    "spec": "RFC 7636",
    "requires_client_secret": false,
    "requires_user_interaction": true,
    "token_endpoint_auth": false,
    "status": "active",
    "notes": "Not a separate grant_type value: requests use grant_type 'authorization_code' plus code_verifier. RFC 9700 recommends PKCE for all OAuth 2.0 clients. Supersedes the Implicit grant for public clients."
  },
  {
    "type": "client_credentials",
    "name": "Client Credentials",
    "description": "The client authenticates directly with the authorization server using its client ID and secret to obtain an access token, with no user involvement. Intended for machine-to-machine (M2M) communication.",
    "spec": "RFC 6749 §4.4",
    "requires_client_secret": true,
    "requires_user_interaction": false,
    "token_endpoint_auth": true,
    "status": "active",
    "notes": "The client is both the resource owner and the entity requesting access. No refresh tokens are issued."
  },
  {
    "type": "device_code",
    "name": "Device Authorization (Device Code)",
    "description": "Allows devices with limited input capability (smart TVs, CLIs, IoT devices) to obtain an access token by having the user authorize the device on a separate device with a browser.",
    "spec": "RFC 8628",
    "requires_client_secret": false,
    "requires_user_interaction": true,
    "token_endpoint_auth": false,
    "status": "active",
    "notes": "The grant type value is 'urn:ietf:params:oauth:grant-type:device_code'. The device polls the token endpoint while the user completes authorization on a secondary device."
  },
  {
    "type": "implicit",
    "name": "Implicit",
    "description": "The access token is returned directly in the redirect URI fragment without an intermediate authorization code exchange. Originally designed for browser-based JavaScript apps.",
    "spec": "RFC 6749 §4.2",
    "requires_client_secret": false,
    "requires_user_interaction": true,
    "token_endpoint_auth": false,
    "status": "deprecated",
    "notes": "RFC 9700 (OAuth 2.0 Security BCP) says the Implicit grant SHOULD NOT be used, and the OAuth 2.1 draft removes it. Public clients should use Authorization Code with PKCE instead."
  },
  {
    "type": "jwt_bearer",
    "name": "JWT Bearer Token",
    "description": "A client presents a JWT (signed by the client's private key or a shared secret) as an assertion to obtain an access token, enabling federated identity and single sign-on scenarios without user redirection.",
    "spec": "RFC 7523",
    "requires_client_secret": false,
    "requires_user_interaction": false,
    "token_endpoint_auth": true,
    "status": "active",
    "notes": "The grant type value is 'urn:ietf:params:oauth:grant-type:jwt-bearer'. Requires the authorization server to trust the issuer of the JWT."
  },
  {
    "type": "password",
    "name": "Resource Owner Password Credentials",
    "description": "The client collects the user's username and password directly and exchanges them for an access token. Only suitable when the client is highly trusted, such as first-party applications.",
    "spec": "RFC 6749 §4.3",
    "requires_client_secret": false,
    "requires_user_interaction": true,
    "token_endpoint_auth": false,
    "status": "deprecated",
    "notes": "RFC 9700 (OAuth 2.0 Security BCP) says this grant MUST NOT be used, and the OAuth 2.1 draft removes it. It exposes user credentials to the client; use Authorization Code with PKCE instead."
  },
  {
    "type": "refresh_token",
    "name": "Refresh Token",
    "description": "The client presents a refresh token (previously issued alongside an access token) to obtain a new access token without re-involving the user. Allows long-lived access without requiring re-authentication.",
    "spec": "RFC 6749 §6",
    "requires_client_secret": false,
    "requires_user_interaction": false,
    "token_endpoint_auth": false,
    "status": "active",
    "notes": "Not a standalone grant; used in conjunction with other grants that issue refresh tokens (e.g., authorization_code). Refresh token rotation is recommended for public clients."
  },
  {
    "type": "saml2_bearer",
    "name": "SAML 2.0 Bearer Assertion",
    "description": "A client presents a SAML 2.0 assertion as a credential to obtain an OAuth 2.0 access token, enabling interoperability between SAML-based identity providers and OAuth 2.0 protected resources.",
    "spec": "RFC 7522",
    "requires_client_secret": false,
    "requires_user_interaction": false,
    "token_endpoint_auth": true,
    "status": "active",
    "notes": "The grant type value is 'urn:ietf:params:oauth:grant-type:saml2-bearer'. Useful in enterprise environments with existing SAML infrastructure."
  },
  {
    "type": "token_exchange",
    "name": "Token Exchange",
    "description": "Allows a client to exchange one security token for another, enabling impersonation and delegation scenarios in complex service architectures where one service calls another on behalf of a user.",
    "spec": "RFC 8693",
    "requires_client_secret": false,
    "requires_user_interaction": false,
    "token_endpoint_auth": true,
    "status": "active",
    "notes": "The grant type value is 'urn:ietf:params:oauth:grant-type:token-exchange'. Supports act-as (impersonation) and may-act-on-behalf-of (delegation) semantics."
  }
]