Cloudflare Docs
Cloudflare Zero Trust
Edit this page on GitHub
Set theme to dark (⇧+D)

Application token

Cloudflare Access includes the application token with all authenticated requests to your origin. A typical JWT looks like this:

eyJhbGciOiJSUzI1NiIsImtpZCI6IjkzMzhhYmUxYmFmMmZlNDkyZjY0.eyJhdWQiOlsiOTdlMmFhZ TEyMDEyMWY5MDJkZjhiYzk5ZmMzNDU5MTNh.zLYsHmLEginAQUXdygQo08gLTExWNXsN4jBc6PKdB

As shown above, the JWT contains three Base64-URL values separated by dots:

Unless your application is connected to Access through Cloudflare Tunnel, your application must validate the token to ensure the security of your origin. Validation of the header alone is not sufficient — the JWT and signature must be confirmed to avoid identity spoofing.

{
"alg": "RS256",
"kid": "9338abe1baf2fe492f646a736f25afbf7b025e35c627be4f60c414d4c73069b8",
"typ": "JWT"
}
  • alg identifies the encoding algorithm.
  • kid identifies the key used to sign the token.
  • typ designates the token format.

​​ Payload

{
"aud": [
"32eafc7626e974616deaf0dc3ce63d7bcbed58a2731e84d06bc3cdf1b53c4228"
],
"email": "[email protected]",
"exp": 1659474457,
"iat": 1659474397,
"nbf": 1659474397,
"iss": "https://yourteam.cloudflareaccess.com",
"type": "app",
"identity_nonce": "6ei69kawdKzMIAPF",
"sub": "7335d417-61da-459d-899c-0a01c76a2f94",
"country": "US"
}

The payload contains the actual claim and user information to pass to the application.

FieldDescription
audThe audience tag for the application to which the token is issued.
emailThe email address of the authenticated user.
expThe expiration timestamp for the token.
iatThe issuance timestamp for the token.
nbfThe not-before timestamp for the token, used to checks if the token was received before it should be used.
issThe Cloudflare Access domain URL for the application.
typeThe type of Access token (app for application token or org for global session token).
identity_nonceA nonce used to get the user’s identity.
subThe ID of the user.
countryThe country where the user authenticated from.

​​ Custom SAML attributes and OIDC claims

Access allows you to add custom SAML attributes and OIDC claims to your JWT for enhanced verification, if supported by your identity provider. This is configured when you setup your SAML or OIDC provider.

​​ User identity

User identity is useful for checking application permissions. For example, your application can validate that a given user is a member of an Okta or AzureAD group such as Finance-Team.

Due to cookie size limits and bandwidth considerations, the application token only contains a subset of the user’s identity. To get the user’s full identity, send the CF_Authorization cookie to https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/get-identity. Your request should be structured as follows:

$ curl -H 'cookie: CF_Authorization=<user-token>' https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/get-identity

Access will return a JSON structure containing the following data:

FieldDescription
emailThe email address of the user.
idpData from your identity provider.
geoThe country where the user authenticated from.
user_uuidThe ID of the user.
devicePostureThe device posture attributes.
account_idThe account ID for your organization.
iatThe timestamp indicating when the user logged in.
ipThe IP address of the user.
auth_statusThe status if authenticating with mTLS.
common_nameThe common name on the mTLS client certificate.
service_token_idThe ID of the service token used for authentication.
service_token_statusTrue if authentication was through a service token instead of an IdP.
is_warpTrue if the user enabled WARP.
is_gatewayTrue if the user enabled WARP and authenticated to a Zero Trust team.
gateway_account_idAn ID generated by the WARP client when authenticated to a Zero Trust team.
device_idThe ID of the device used for authentication.
versionThe version of the get-identity object.
device_sessionsA list of all sessions initiated by the user.

​​ Signature

Cloudflare generates the signature by signing the encoded header and payload using the SHA-256 algorithm (RS256). In RS256, a private key signs the JWTs and a separate public key verifies the signature.

For more information on JWTs, refer to jwt.io.