JWT Sign — Reference

Create a signed token with explicitly chosen claims and expiry.

Before you begin

• A Server Connect action. Test security behavior with an isolated test account or test-only token/key, not production credentials.

JWT Sign

Create a signed token with explicitly chosen claims and expiry.

Settings

Setting	Meaning and example
Name	Names the token result and its server-side JWT configuration/cache entry. The result is a compact string, not an authenticated session.
Service	The current inspector offers a Google-oriented configuration. This is editor assistance; it does not contact the provider or exchange a signed assertion for an access token.
Import Service Account	Reads the selected service-account JSON and fills Algorithm RS256, Key from private_key, Issuer from client_email and Audience from token_uri. It imports credentials into this server configuration; it does not complete authorization.
Algorithm	Choose the signing algorithm expected by the verifier: RS256/RS384/RS512 use an RSA private key; HS256/HS384/HS512 use a shared secret. The matching verifier must enforce the intended algorithm and key type.
Issuer	Sets the iss claim, identifying the issuer according to the receiving service’s contract.
Subject	Sets sub, identifying the token’s subject. For example, a service-defined account or user identifier.
Audience	Sets aud, identifying the intended recipient. Adding it to a token does not mean every verifier automatically checks it.
JWT ID	Sets jti, an identifier for the token. It does not by itself implement replay protection or revocation.
Expires In	The runtime default is 3600 seconds. Use a numeric value, such as the server expression {{3600}}, for portability. Node.js jsonwebtoken also accepts duration strings; a bare numeric string is interpreted differently from a number. PHP adds the value as seconds.
Key	The private signing key for RS algorithms or shared secret for HS algorithms. Keep it server-side and separate from public page data.
Claims	Additional payload fields required by the receiving service. Signed claims are readable, not encrypted. Avoid duplicating reserved claims in multiple controls.

Verification example

In an isolated test, use an explicit signing algorithm, a test-only key, a subject such as documentation-user and a numeric expiry. Verify the resulting token with the corresponding verification key. Then verify a tampered token and an expired token and confirm both are rejected before using the claims.

Behavior and limits

The installed PHP signer adds nbf at the current time plus 60 seconds by default; Node.js does not add that future not-before value unless present in claims. Consumers may reject a new PHP token until that time. Signing a service assertion is also distinct from exchanging it for a provider access token.

Use the complete authentication flow

Use the security and login guides for the surrounding provider, form, session and server-access configuration.

Check your result

You can configure the documented fields and distinguish a successful result from the failure or limitation described here.