Jwt Objective-C Reference Documentation

CkoJwt

Current Version: 11.5.0

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.

Object Creation

CkoJwt *obj = [[CkoJwt alloc] init];

Properties

AutoCompact
@property (nonatomic) BOOL AutoCompact;
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 YES.

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
@property (nonatomic, copy) NSString *DebugLogFilePath;

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
top
LastErrorHtml
@property (nonatomic, readonly, copy) NSString *LastErrorHtml;

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
@property (nonatomic, readonly, copy) NSString *LastErrorText;

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.

top
LastErrorXml
@property (nonatomic, readonly, copy) NSString *LastErrorXml;

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
@property (nonatomic) BOOL LastMethodSuccess;

Indicates the success or failure of the most recent method call: YES means success, NO 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
@property (nonatomic, copy) NSString *UncommonOptions;
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
@property (nonatomic) BOOL VerboseLogging;

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

top
Version
@property (nonatomic, readonly, copy) NSString *Version;

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

More Information and Examples
top

Methods

CreateJwt
- (NSString *)CreateJwt:(NSString *)header
    payload:(NSString *)payload
    password:(NSString *)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 nil on failure

top
CreateJwtCert
- (NSString *)CreateJwtCert:(NSString *)header
    payload:(NSString *)payload
    cert:(CkoCert *)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 nil on failure

More Information and Examples
top
CreateJwtPk
- (NSString *)CreateJwtPk:(NSString *)header
    payload:(NSString *)payload
    key:(CkoPrivateKey *)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 nil on failure

top
GenNumericDate
- (NSNumber *)GenNumericDate:(NSNumber *)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
top
GetHeader
- (NSString *)GetHeader:(NSString *)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 nil on failure

More Information and Examples
top
GetPayload
- (NSString *)GetPayload:(NSString *)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 nil on failure

top
IsTimeValid
- (BOOL)IsTimeValid:(NSString *)jwt
    leeway:(NSNumber *)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 YES when every present time constraint permits the token to be used, and NO 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
top
VerifyJwt
- (BOOL)VerifyJwt:(NSString *)token
    password:(NSString *)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 YES 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 YES for success, NO for failure.

More Information and Examples
top
VerifyJwtPk
- (BOOL)VerifyJwtPk:(NSString *)token
    key:(CkoPublicKey *)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 YES only when the signature is valid. It returns NO 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 YES for success, NO for failure.

top