Jwt C# Reference Documentation

Jwt

Current Version: 11.5.0
Requires Chilkat Bundle License

Chilkat.Jwt

Create, decode, verify, and time-validate compact JSON Web Tokens.

Chilkat.Jwt is the Chilkat class for working with compact JSON Web Tokens. It can create signed JWTs, decode JWT headers and payloads, verify signatures, validate time-based claims, generate NumericDate values, and work with HMAC shared-secret tokens, RSA public/private-key tokens, ECC public/private-key tokens, and certificate-backed signing workflows.

Create compact JWTs

Build JWTs from JSON header and payload data, then sign them using the algorithm and key material required by the application or API.

Decode headers and claims

Decode the JWT header and payload without verification when an application needs to inspect claims, algorithms, key IDs, or token metadata.

Verify signatures

Verify JWT signatures using HMAC shared secrets, RSA public keys, ECC public keys, or certificates.

Sign with keys or certs

Create tokens using shared secrets, private keys, or certificates that have access to the associated private key.

Time validation

Validate exp and nbf claims and generate NumericDate values for token expiration, not-before, and issued-at timestamps.

API authentication workflows

Use JWTs for bearer-token style authentication, service-account flows, assertion-based OAuth flows, and other compact token formats.

Common pattern: To create a JWT, prepare the JSON header and payload, set claims such as iss, sub, aud, iat, nbf, or exp, then sign with the required shared secret, private key, or certificate. To consume a JWT, decode it as needed, verify the signature with the matching key, and separately validate the time-based claims required by the application.

For an extended overview, see Jwt Class Overview.

Object Creation

Chilkat.Jwt obj = new Chilkat.Jwt();

Properties

AutoCompact
public bool AutoCompact {get; set; }
Introduced in version 9.5.0.58

Controls whether Chilkat removes insignificant JSON whitespace from the header and payload passed to CreateJwt and CreateJwtPk before Base64URL encoding and signing. The default is true.

Compaction reduces token size without changing the JSON data model. Because the exact header and payload bytes are part of the signing input, changing this property changes the encoded token and its signature even when the JSON values are equivalent.

Whitespace inside JSON strings is preserved: Compaction removes formatting whitespace between JSON tokens; it does not remove spaces that are part of a quoted string value.

top
DebugLogFilePath
public string DebugLogFilePath {get; set; }

If set to a file path, this property logs the LastErrorText of each Chilkat method or property call to the specified file. This logging helps identify the context and history of Chilkat calls leading up to any crash or hang, aiding in debugging.

Enabling the VerboseLogging property provides more detailed information. This property is mainly used for debugging rare instances where a Chilkat method call causes a hang or crash, which should generally not happen.

Possible causes of hangs include:

  • A timeout property set to 0, indicating an infinite timeout.
  • A hang occurring within an event callback in the application code.
  • An internal bug in the Chilkat code causing the hang.

More Information and Examples
(C#) Example showing how to use DebugLogFilePath.(PowerShell) Example showing how to use DebugLogFilePath.
top
LastErrorHtml
public string LastErrorHtml {get; }

Provides HTML-formatted information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top
LastErrorText
public string LastErrorText {get; }

Provides plain text information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

More Information and Examples
Concept of LastErrorTextLastErrorText Standard Information
top
LastErrorXml
public string LastErrorXml {get; }

Provides XML-formatted information about the last called method or property. If a method call fails or behaves unexpectedly, check this property for details. Note that information is available regardless of the method call's success.

top
LastMethodSuccess
public bool LastMethodSuccess {get; set; }

Indicates the success or failure of the most recent method call: true means success, false means failure. This property remains unchanged by property setters or getters. This method is present to address challenges in checking for null or Nothing returns in certain programming languages. Note: This property does not apply to methods that return integer values or to boolean-returning methods where the boolean does not indicate success or failure.

top
UncommonOptions
public string UncommonOptions {get; set; }
Introduced in version 10.1.0

Provides a catch-all string for specialized compatibility options that are not exposed as ordinary properties. The default is the empty string, which is appropriate for normal use.

Leave empty unless instructed: Set this property only when a Chilkat example, release note, or support response documents a specific option needed for an unusual interoperability case.

top
VerboseLogging
public bool VerboseLogging {get; set; }

If set to true, then the contents of LastErrorText (or LastErrorXml, or LastErrorHtml) may contain more verbose information. The default value is false. Verbose logging should only be used for debugging. The potentially large quantity of logged information may adversely affect peformance.

top
Version
public string Version {get; }

Version of the component/library, such as "10.1.0"

More Information and Examples
(C#) How to get the Chilkat version at runtime.(PowerShell) How to get the Chilkat version at runtime.
top

Methods

CreateJwt
public string CreateJwt(string header, string payload, string password);
Introduced in version 9.5.0.58

Creates a signed JWT using an HMAC shared secret. header may be a complete JOSE header JSON object or the shorthand HS256, HS384, or HS512. A shorthand value produces a standard header containing the corresponding alg value.

payload is the JSON claims set. Chilkat signs the JSON supplied by the application; it does not automatically add claims such as iss, sub, aud, iat, nbf, or exp. password is the shared secret used by both the signer and verifier.

AlgorithmOperation
HS256HMAC with SHA-256.
HS384HMAC with SHA-384.
HS512HMAC with SHA-512.

On success, the result is a compact JWS in the form base64url(header).base64url(payload).base64url(signature). The Base64URL segments do not use padding.

Signed, not encrypted: Anyone who receives the token can decode its header and payload. The HMAC protects integrity and authenticity only; do not place confidential information in the claims unless the token is protected separately.
Shared-secret guidance: Use a high-entropy secret appropriate for the selected HMAC algorithm. A human password is usually weaker than a randomly generated key. Use CreateJwtPk when the trust model requires an asymmetric private key.

Returns null on failure

More Information and Examples
(C#) Create JWT Using HS256, HS384, or HS512(PowerShell) Create JWT Using HS256, HS384, or HS512(C#) Firebase JWT User Authentication(PowerShell) Firebase JWT User Authentication(C#) Zoom API - Create JWT to Authenticate API Requests(PowerShell) Zoom API - Create JWT to Authenticate API Requests
top
CreateJwtCert
public string CreateJwtCert(string header, string payload, Cert cert);
Introduced in version 9.5.0.99

Creates a signed JWT using the private key associated with cert. The certificate must provide access to an RSA or EC private key compatible with the alg value in header.

header may be a complete JOSE header JSON object or the shorthand RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, or ES512. payload is the JSON claims set. PS256/384/512 support was added in Chilkat v10.0.0.

On success, the result is a compact JWS in the form base64url(header).base64url(payload).base64url(signature).

Private-key access is required: A certificate containing only the public key cannot create a signature. Signing can also fail when the private key exists but is not accessible, is nonfunctional, requires unavailable user interaction, or is incompatible with the selected algorithm.
Certificate trust is a verifier decision: Creating a JWT with a certificate-backed key does not by itself establish that recipients should trust that certificate. The verifier must obtain the correct public key or certificate through a trusted mechanism and apply any required certificate validation policy.

Returns null on failure

More Information and Examples
(C#) Create JWT using a Certificate's Private Key(PowerShell) Create JWT using a Certificate's Private Key
top
CreateJwtPk
public string CreateJwtPk(string header, string payload, PrivateKey key);
Introduced in version 9.5.0.58

Creates a signed JWT using an asymmetric private key. header may be a complete JOSE header JSON object or one of the documented shorthand algorithm names. payload is the JSON claims set, and key must be a private key compatible with the selected alg.

JOSE algorithmRequired key and signature scheme
RS256, RS384, RS512RSA private key; RSASSA-PKCS1-v1_5 with the corresponding SHA-2 digest.
PS256, PS384, PS512RSA private key; RSASSA-PSS with the corresponding SHA-2 digest and MGF1.
ES256, ES384, ES512EC private key compatible with the requested ECDSA algorithm.
EdDSAEd25519 private key. Use a full JOSE header containing "alg":"EdDSA".

The shorthand forms documented for this method are RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, and ES512. PS256/384/512 support was added in Chilkat v10.0.0; Ed25519 signing with EdDSA requires Chilkat v9.5.0.95 or later.

On success, the result is a compact JWS in the form base64url(header).base64url(payload).base64url(signature).

Key compatibility: The private-key type must agree with alg. Do not select an algorithm solely from untrusted input. Choose the algorithm as part of the application protocol and use a key intended for that algorithm.
Claims remain application-defined: This method creates the cryptographic signature. The application is responsible for constructing and later validating issuer, audience, subject, lifetime, nonce, and other required claims.

Returns null on failure

More Information and Examples
(C#) Create JWT Using RSA (RS256, RS384, or RS512)(PowerShell) Create JWT Using RSA (RS256, RS384, or RS512)(C#) Create JWT Using ECC (ES256, ES384, or ES512)(PowerShell) Create JWT Using ECC (ES256, ES384, or ES512)(C#) Create JWT using a Brainpool EC Key(PowerShell) Create JWT using a Brainpool EC Key
top
GenNumericDate
public int GenNumericDate(int numSecOffset);
Introduced in version 9.5.0.58

Returns a JWT NumericDate equal to the current system time plus numSecOffset. The result is the number of whole seconds elapsed since 1970-01-01T00:00:00Z, ignoring leap seconds.

A positive offset produces a future time and a negative offset produces a past time. Typical uses include generating values for iat, nbf, and exp claims. The method returns the numeric value only; it does not insert the value into a JSON payload.

System-clock dependency: The result is based on the computer's current clock. Token lifetimes and validation can be incorrect when the system clock is inaccurate.
More Information and Examples
(C#) Create JWT Using HS256, HS384, or HS512(PowerShell) Create JWT Using HS256, HS384, or HS512
top
GetHeader
public string GetHeader(string token);
Introduced in version 9.5.0.58

Decodes and returns the JOSE header JSON from the first segment of the compact JWT. For a token in the form header.payload.signature, this method Base64URL-decodes the header segment and interprets it as JSON text.

No verification is performed: Decoding a header does not prove that the token is authentic. Until VerifyJwt or VerifyJwtPk succeeds, treat every header value—including alg, kid, jku, and x5u—as attacker-controlled input.

The method fails if the token does not contain a decodable compact-JWT header.

Returns null on failure

More Information and Examples
(C#) Verify JWT Using HS256, HS384, or HS512(PowerShell) Verify JWT Using HS256, HS384, or HS512
top
GetPayload
public string GetPayload(string token);
Introduced in version 9.5.0.58

Decodes and returns the claims-set JSON from the second segment of the compact JWT. For a token in the form header.payload.signature, this method Base64URL-decodes the payload segment and returns the resulting JSON text.

Decoding is not validation: This method does not verify the signature, token lifetime, issuer, audience, nonce, or any other claim. Use the appropriate signature-verification method first, then apply the claim checks required by the application.

The method fails if the token does not contain a decodable compact-JWT payload.

Returns null on failure

More Information and Examples
(C#) Verify JWT Using HS256, HS384, or HS512(PowerShell) Verify JWT Using HS256, HS384, or HS512(C#) Decode Microsoft Graph ID Token(PowerShell) Decode Microsoft Graph ID Token(C#) Validate the at_hash Claim of an ID Token(PowerShell) Validate the at_hash Claim of an ID Token
top
IsTimeValid
public bool IsTimeValid(string jwt, int leeway);
Introduced in version 9.5.0.58

Checks the JWT exp (expiration time) and nbf (not before) claims against the current system time. It returns true when every present time constraint permits the token to be used, and false when the token is expired, is not yet valid, or its relevant time data cannot be processed.

ClaimValidity rule
expThe token is not accepted on or after the expiration time.
nbfThe token is not accepted before the not-before time.

leeway is a number of seconds allowed for clock skew. Keep it small; a few minutes is typical. The method checks whichever of exp and nbf are present and does not require either claim to exist.

Time checking is separate from signature verification: IsTimeValid does not verify the JWT signature and does not validate iss, aud, sub, iat, jti, nonce values, or application-specific claims. A normal validation workflow verifies the signature, checks time constraints, and then validates all required claims.
More Information and Examples
(C#) Verify JWT Using HS256, HS384, or HS512(PowerShell) Verify JWT Using HS256, HS384, or HS512
top
VerifyJwt
public bool VerifyJwt(string token, string password);
Introduced in version 9.5.0.58

Verifies the signature of a compact JWT signed with the shared secret in password. This method accepts only the HMAC algorithms HS256, HS384, and HS512. It rejects none and algorithms intended for asymmetric keys.

Chilkat reads the token's alg value, computes the corresponding HMAC over the encoded header and payload, and compares the result with the signature segment. The method returns true only when the signature matches.

Signature verification only: A successful result does not validate expiration, not-before time, issuer, audience, subject, or any other claim. Call IsTimeValid and perform the application's required claim checks separately.
Enforce the expected algorithm: Applications should inspect the verified header and require the specific HMAC algorithm allowed by their protocol rather than accepting any algorithm merely because this method supports it.

Returns true for success, false for failure.

More Information and Examples
(C#) Verify JWT Using HS256, HS384, or HS512(PowerShell) Verify JWT Using HS256, HS384, or HS512
top
VerifyJwtPk
public bool VerifyJwtPk(string token, PublicKey key);
Introduced in version 9.5.0.58

Verifies the signature of a compact JWT using key. The public key must match the private key that created the signature and must be compatible with the algorithm named by the token's alg header.

JOSE algorithmVerification key
RS256, RS384, RS512RSA public key for RSASSA-PKCS1-v1_5.
PS256, PS384, PS512RSA public key for RSASSA-PSS.
ES256, ES384, ES512EC public key compatible with the ECDSA algorithm.
EdDSAEd25519 public key. Ed25519 verification requires Chilkat v9.5.0.84 or later.

The method returns true only when the signature is valid. It returns false for a malformed token, unsupported or incompatible algorithm/key combination, incorrect key, or invalid signature. The unsecured none algorithm is rejected.

Use a trusted key-selection process: Do not automatically trust a key URL or key identifier taken from an unverified JWT header. Select the verification key from trusted configuration or a securely obtained and validated key set, and enforce the expected algorithm.
Claims are not checked: Signature validity proves only that the token was signed by the holder of the corresponding private key and was not modified. Validate time, issuer, audience, nonce, and all other required claims separately.

Returns true for success, false for failure.

More Information and Examples
(C#) Verify JWT Using an RSA Public Key (RS256, RS384, RS512)(PowerShell) Verify JWT Using an RSA Public Key (RS256, RS384, RS512)(C#) Verify JWT Using an ECC Public Key (ES256, ES384, ES512)(PowerShell) Verify JWT Using an ECC Public Key (ES256, ES384, ES512)(C#) Verify JWT with EdDSA / Ed25519 Signature(PowerShell) Verify JWT with EdDSA / Ed25519 Signature
top