Session and storage

After a successful login, the SDK persists the session in the browser so the user does not have to sign in again on every page load.

The user unlocked private keys never leave the browser. They are stored on the device and are never sent to the Secrecy servers, which only hold them locked.

What is stored

Four entries are written by the SDK:

Key	Content
`secrecy.user_app_session`	The user application session identifier
`secrecy.identities`	The identities the user has access to
`secrecy.key_pairs`	The key pairs used to encrypt and decrypt
`secrecy.jwt`	The application JWT

Restore the client on page load

The getSecrecyClient function rebuilds a client from those entries. It returns null when nothing has been stored yet, which is the signal to start a login.

auth.ts

const restoreClient = async (): Promise<SecrecyClient | null> => {
  // The crypto library has to be ready before reading the stored key pairs
  await setup();
 
  const client = getSecrecyClient();
 
  if (!client) {
    // Nothing stored yet, the user has to log in
    return null;
  }
 
  return client;
};

Keep the session for the tab only

By default the credentials are written to localStorage, so they survive a browser restart. Pass session: true to use sessionStorage instead: the session is then dropped when the tab is closed.

auth.ts

const restoreTabClient = async (): Promise<SecrecyClient | null> => {
  await setup();
 
  // Read the credentials from sessionStorage instead of localStorage
  return getSecrecyClient({ session: true });
};

⚠️

The same session value has to be passed to login and to getSecrecyClient, otherwise the client is looked up in the wrong storage.