OAuth 2.0 Grant Types

Name: OAuth 2.0 Grant Types
Creator: staticdata.dev
License: https://opensource.org/licenses/MIT

A reference to the main OAuth 2.0 grant types as defined by RFC 6749 and its extensions (RFC 7523, RFC 7522, RFC 7636, RFC 8628, RFC 8693). Each entry includes the grant type identifier, a human-readable name, a concise description of the flow, the governing specification, client and user interaction requirements, and the current status (active or deprecated).

v1.0.0 MIT 10 records Updated 2026-10-05 stable Source: RFC 6749 - The OAuth 2.0 Authorization Framework, RFC 7636 - Proof Key for Code Exchange (PKCE), RFC 8628 - OAuth 2.0 Device Authorization Grant, RFC 7523 - JWT Bearer Token Grant, RFC 7522 - SAML 2.0 Bearer Assertion Grant, RFC 8693 - OAuth 2.0 Token Exchange, RFC 9700 - OAuth 2.0 Security Best Current Practice

Quick fetch

Stable URL. CORS-enabled. No auth.

bash

curl https://staticdata.dev/v1/oauth-grant-types.json

Or use as a typed import: import { oauthGrantTypes } from "https://staticdata.dev/v1/oauth-grant-types.ts"

Formats

JSON 6.1 KB

/v1/oauth-grant-types.json

Open

min: 5.5 KB · /v1/oauth-grant-types.min.json
CSV 4.3 KB

/v1/oauth-grant-types.csv

Open
TypeScript 6.3 KB

/v1/oauth-grant-types.ts

export const oauthGrantTypes

type OauthGrantType = (typeof oauthGrantTypes)[number]

Open

Schema

Each record in the dataset has the following shape.

Schema
Field	Type	Description	Example
type	string	Grant type identifier used at the token endpoint	authorization_code
name	string	Human-readable name of the grant type	Authorization Code
description	string	Description of the grant flow and intended use case	The client redirects the user...
spec	string	Governing RFC or specification section	RFC 6749 §4.1
requires_client_secret	boolean	Whether the client must authenticate with a secret	true
requires_user_interaction	boolean	Whether the flow requires a human user to interact	true
token_endpoint_auth	boolean	Whether the client authenticates at the token endpoint	true
status	string	Current status: active or deprecated	active
notes	string	Implementation notes, security guidance, or migration advice	Should be used with PKCE.

Preview

First 10 records.

Data preview
type	name	description	spec	requires_client_secret	requires_user_interaction
authorization_code	Authorization Code	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.	RFC 6749 §4.1	true	true
authorization_code_with_pkce	Authorization Code with PKCE	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.	RFC 7636	false	true
client_credentials	Client Credentials	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.	RFC 6749 §4.4	true	false
device_code	Device Authorization (Device Code)	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.	RFC 8628	false	true
implicit	Implicit	The access token is returned directly in the redirect URI fragment without an intermediate authorization code exchange. Originally designed for browser-based JavaScript apps.	RFC 6749 §4.2	false	true
jwt_bearer	JWT Bearer Token	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.	RFC 7523	false	false
password	Resource Owner Password Credentials	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.	RFC 6749 §4.3	false	true
refresh_token	Refresh Token	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.	RFC 6749 §6	false	false
saml2_bearer	SAML 2.0 Bearer Assertion	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.	RFC 7522	false	false
token_exchange	Token Exchange	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.	RFC 8693	false	false

Showing 10 of 10. View full data: JSON · CSV

Fetch examples

Drop-in snippets in five languages.

curl

curl -sSL https://staticdata.dev/v1/oauth-grant-types.json | jq '.[0]'

JavaScript

import type { OauthGrantType } from "https://staticdata.dev/v1/oauth-grant-types.ts";

const res = await fetch("https://staticdata.dev/v1/oauth-grant-types.min.json");
if (!res.ok) throw new Error(`Fetch failed: ${res.status}`);
const oauthGrantTypes: OauthGrantType[] = await res.json();
console.log(oauthGrantTypes[0]);

Python

import urllib.request, json

with urllib.request.urlopen("https://staticdata.dev/v1/oauth-grant-types.min.json") as r:
    oauthGrantTypes = json.load(r)

print(oauthGrantTypes[0])

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
)

func main() {
	resp, err := http.Get("https://staticdata.dev/v1/oauth-grant-types.min.json")
	if err != nil { panic(err) }
	defer resp.Body.Close()

	var data []map[string]any
	if err := json.NewDecoder(resp.Body).Decode(&data); err != nil {
		panic(err)
	}
	fmt.Println(data[0])
}

Rust

use serde_json::Value;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let body = ureq::get("https://staticdata.dev/v1/oauth-grant-types.min.json").call()?.into_string()?;
    let data: Vec<Value> = serde_json::from_str(&body)?;
    println!("{:?}", data.first());
    Ok(())
}

Sources and methodology

The dataset covers all major OAuth 2.0 grant types defined in RFC 6749 (Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials, and Refresh Token) as well as widely-adopted extensions: PKCE (RFC 7636), Device Authorization (RFC 8628), JWT Bearer (RFC 7523), SAML 2.0 Bearer (RFC 7522), and Token Exchange (RFC 8693). Data is curated directly from the respective IETF RFCs and the IANA OAuth Parameters registry. Other registered extension grants, such as OpenID Connect CIBA (urn:openid:params:grant-type:ciba) and the OpenID4VCI pre-authorized code grant, are not included.

Two grant types — Implicit and Resource Owner Password Credentials — are marked as deprecated following RFC 9700 (OAuth 2.0 Security Best Current Practice, January 2025); status reflects guidance as of October 2026. PKCE is treated as a separate entry (authorization_code_with_pkce) rather than a flag on the Authorization Code grant, because it changes the client authentication model: public clients using PKCE do not present a client_secret. The type field for the URN-based grants uses short identifiers (device_code, jwt_bearer, saml2_bearer, token_exchange) for readability; the actual grant_type URN values (for example urn:ietf:params:oauth:grant-type:jwt-bearer) appear in the notes field. Likewise authorization_code_with_pkce is a dataset label, not a wire value: PKCE requests still send grant_type=authorization_code.

The token_endpoint_auth field indicates whether the client must authenticate at the /token endpoint (as opposed to flows where the client is public or the credential is the assertion itself). The requires_user_interaction field distinguishes user-facing flows (where a browser redirect or device display is needed) from machine-to-machine flows that complete entirely server-side.

Versioning

URLs under /v1/ are stable: field names and types will not change in a way that breaks consumers. Values can be corrected or records added when the upstream source changes; schema-incompatible updates ship under a new version path. See the oauth-grant-types changelog for this dataset's history.