Status codes

The Relock service returns the following status codes to signal specific conditions related to device trust, user authentication, session integrity, and potential security threats. Understanding these codes is critical for debugging and ensuring proper system behavior.

200 - OK

All clear: Request secure and validated.

A 200 OK status from the Relock service signifies successful request processing and validation. This indicates that:

  • The client’s request was well-formed.

  • Device trust was confirmed.

  • User authentication and session integrity were verified.

  • Any necessary cryptographic key rotations or session renewals (as part of Relock’s continuous authentication) completed successfully.

This status confirms that communication is secure, trusted, and can proceed as expected by the application server.

400 - Bad Request

Device cookie is invalid or missing.

The Relock service returns a 400 Bad Request error if the cookie used to confirm possession of trusted assets on the client side is invalid or missing. This condition typically points to:

  • Possible data manipulation in the browser.

  • Suspected malicious behavior.

In such cases, the device can no longer be considered trusted.

Warning

To restore access, a fresh trust establishment process is required for both the user and the affected device.

401 - Unauthorized

Access denied: Unauthenticated device or user.

A 401 Unauthorized error indicates that access to a protected URL (route) is denied because the request lacks:

  • An authenticated, active Relock-side user session.

  • Recognized device credentials with an assigned owner.

This may occur if the user has never authenticated from the current device, meaning device ownership hasn’t been established. Alternatively, the request might originate from an unauthorized source, lacking both device authentication credentials and an authorized device session. In both scenarios, access is denied, and a session isn’t initiated.

403 - Forbidden

Authenticated user, but device is unassigned.

A 403 Forbidden error is returned when a user is authenticated in the web application but has never been authenticated within the Relock service, leaving their device unassigned in Relock data. This occurs when user/device access is attempted on protected (non-exposed) routes.

Note

This differs from a 401 Unauthorized error: the device already exists in Relock’s storage, but because it has no associated user, it’s treated as unauthorized for protected resource access.

To resolve this, the application server must complete the initial device trust establishment flow to assign user ownership and activate the device.

404 - Not Found

Device session is missing or expired.

A 404 Not Found status indicates that the device session no longer exists in the Relock service, likely due to session expiration or deprecation. In such cases, user re-authentication is required to re-establish a valid session.

This condition is informational only and does not affect the current device session’s status with Relock. The Relock service attempts to restore the session using the cookie sent by the client, provided that the device’s cryptographic cookie is valid and the session does not require immediate re-establishment. If re-establishment isn’t possible, a new session must be established through the authentication flow (e.g., via a password prompt).

406 - Not Acceptable

Network change detected; step-up authentication needed.

A 406 Not Acceptable status is returned if the Relock service detects a change in network location during an active session. Such a change indicates a potentially unsafe request that should not be processed by the application server.

While Relock can be optionally configured to automatically re-authenticate using the device’s cryptographic keys in such cases, this is not recommended due to increased risk of session hijacking or unauthorized access. Instead, the user must undergo step-up authentication, requiring an additional second factor (e.g., a password or MFA code) to confirm their identity.

Note

At a minimum, the web application should prompt the user for a low-friction second factor to confirm their identity and maintain session trust integrity.

409 - Conflict

Device data is corrupted or unavailable.

A 409 Conflict error occurs when the device data on the Relock service side is either corrupted or no longer exists, preventing the Relock service from validating information sent by the browser.

If permitted by the administrator, the Relock service will automatically create a new, fresh device record and continue step-up authentication. Otherwise, manual intervention by an administrator will be required to unlock the user’s account or restore it.

A device record may become unavailable due to:

  • The user has not accessed the service domain for an extended period, and the device record has expired.

  • The device data was manually removed during system maintenance or cleanup procedures.

Note

The conflict error typically originates server-side and is not a symptom of data manipulation on the browser-side. However, it may require cleaning up browser-side keys and new device registration.

410 - Gone

Device cookie key missing; session terminated.

A 410 Gone status indicates that the Relock service could not find the device cookie key, typically because the browser sent an invalid or deprecated cookie that cannot be decrypted server-side. The associated cryptographic key is no longer present in server storage.

Since the device cookie key is intended to live as long as the device data itself, its absence may indicate: - Malicious behavior or tampering. - Manual deletion of server-side key material. - Inconsistent or outdated browser state.

As a result, the origin of the request cannot be verified, and session trust is considered broken. The session has been terminated for security reasons.

To recover:

  • A fresh trust establishment process is required for the user and device.

  • The user may need to clear stored browser-side keys and undergo new device registration.

Warning

To restore access, a fresh trust establishment process is required for both the user and the affected device.

417 - Expectation Failed

Key validation failed: Security threat.

A 417 Expectation Failed status indicates a key validation failure where data provided by the browser does not match the corresponding server-side record. This failure may be caused by:

  • An invalid or incorrect data signature sent by the browser.

  • A failed proof of the ephemeral key due to an invalid or deprecated token.

  • A nonce mismatch, potentially indicating a request outside the secure sandbox.

This condition is treated as a potential security threat, resulting in:

  • Immediate termination of the Relock-side session.

  • Blocking of the device on the Relock service.

  • The incident being considered indicative of malicious activity.

Warning

To restore access, a fresh trust establishment process is required for both the user and the affected device.

423 - Locked

Session is locked, inactive, or gone.

A 423 Locked status indicates that the Relock service has locked the session because it no longer exists or is inaccessible. This often occurs when a user attempts to access a session that has been terminated or expired on the Relock side.

426 - Upgrade Required

Known device, but session not found; re-authentication needed.

A 426 Upgrade Required status may be returned if the Relock service requires the user to re-authenticate under specific conditions, such as:

  • The device is known and recognized by the Relock service.

  • The device attempts to access a session that no longer exists (e.g., expired, revoked, or deleted).

In this case, the Relock service will return an error indicating that session recovery is not possible.

Note

The application should treat this as a critical session failure, log the user out, and initiate a full re-authentication flow to re-establish session and device trust.

503 - Service Unavailable

Unexpected infrastructure failure (e.g., TCP socket break).

A 503 Service Unavailable status indicates an unexpected failure, most commonly if the underlying TCP socket is broken during communication between the client (web app server) and the Relock service. In such cases, it is appropriate for the web app server to return a 503 Service Unavailable (or a 500 Internal Server Error), as the issue is likely infrastructure-related rather than caused by user behavior. A broken TCP connection to the Relock service may lead to unstable behavior, potentially compromising the key chain.