Appcelerator Titanium Cloud session token expiration limits

Session Token Expiration and Renewal

Is there a documented method to extend a session token's validity without the user's original credentials?
No. The Appcelerator Titanium Cloud SDK does not provide a refresh token or a method to extend the 24-hour Time-to-Live (TTL) of a session token. To obtain a new token, the application must re-invoke Ti.Cloud.Users.login using the user's credentials.

What is the recommended architectural pattern for handling 401 responses?
Implement a request wrapper or interceptor for all Cloud API calls. This wrapper should follow this logic:

• Monitor for a 401 Unauthorized response.
• Attempt a silent re-authentication using credentials stored securely on the device (e.g., Keychain or Keystore).
• If re-authentication succeeds, retry the original request once.
• If silent login fails or credentials are not stored, trigger the user-facing login interface.
• Enforce a strict retry limit (maximum one attempt) to prevent infinite loops during authentication failure.

Implementation Details

Confirmed Behavior

• Session tokens issued via Ti.Cloud.Users.login expire exactly 24 hours after issuance.
• The server returns a 401 error immediately upon token expiration.
• Successful re-login provides a new token that restores API access.

Likely Explanation

Since the SDK lacks a native refresh mechanism, the industry standard for Titanium apps is to store encrypted credentials locally. This allows the app to maintain session continuity for background processes without interrupting the user experience.

Recommended Implementation Steps

1. Secure Storage: Store user credentials using platform-specific secure storage. Avoid plain-text files.
2. Request Wrapper: Create a utility function to handle Cloud calls. Example logic:

   function executeCloudCall(action, params, resolve, reject, isRetry = false) {
     Ti.Cloud[action](params, function(response) {
       if (response.success) {
         resolve(response);
       } else if (response.code === 401 && !isRetry) {
         // Attempt silent login
         Ti.Cloud.Users.login({ username: storedUser, password: storedPass }, function(loginRes) {
           if (loginRes.success) {
             executeCloudCall(action, params, resolve, reject, true);
           } else {
             reject(response);
           }
         });
       } else {
         reject(response);
       }
     });
   }

3. Integration: Replace direct Ti.Cloud calls with this wrapper throughout the application.

Diagnostic Considerations

One critical detail that changes this recommendation is whether you store user credentials. If your security policy prohibits storing passwords locally, the silent re-login step is impossible. In this scenario, you must queue pending requests and prompt the user for credentials before retrying the failed operations.

Safety and Verification

• Verification: To test this, record a token, wait 24 hours (or simulate expiration), and verify that the 401 trigger successfully invokes the re-login flow.
• Security: Never log raw tokens or credentials in production logs.
• Scope: Ensure the retry logic is scoped to a single attempt to avoid draining battery or hitting API rate limits during a persistent auth failure.