Sessions

What sessions are 🔗

A session is the credential Layer5 Cloud issues each time someone signs in. It is what keeps a browser tab, a second device, or a connected Meshery Server signed in, and it is what you end when you want one of those sign-ins to stop working. Sessions expire on their own. API tokens do not.

Layer5 Cloud sessions use OAuth 2.0 for authentication. OAuth 2.0 is a standard protocol for authorization and focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and so on.

These are the Layer5 Cloud deployment defaults. Operators of a self-hosted deployment can change them.

The browser keeps the session in the provider_token cookie. Page scripts cannot read it (HttpOnly), it is sent only over HTTPS, and it uses SameSite Lax, so other sites cannot send it along with their own requests except on ordinary top-level navigation. A second cookie, has_session, tells the interface that a session exists. It carries no secret, page scripts can read it, and it lapses with the session.

Creating and using sessions 🔗

Every sign-in creates its own session. Each browser, device, and Meshery Server that signs in through Layer5 Cloud holds a separate session with its own expiry, and any number of them can be active at once. Ending one session leaves the others untouched.

A session acts as the user who signed in. What it can do in an organization is whatever the roles that user holds there allow, checked on every request. See Keys for how roles grant permissions.

To use a session, sign in to your Layer5 Cloud user account. The session cookie is stored in that browser. Use the same browser until the session expires. You can have multiple sessions active concurrently, on the same device or on different devices. Each session receives its own authentication token and expiry time.

It is possible to use the same account from two sessions at once. For example, you may open the same Kanvas design in two sessions and see your avatar twice in the design, along with your mouse cursor. You can use this to collaborate with yourself or with others.

Users see their own sessions on the Sessions tab of the Security page. Each row shows the session’s ID, name, purpose, and creation date. The tab requires the View Sessions key, which every default user role holds. The list shows no device, browser, or location for a session. Search filters by name or purpose, and the newest sessions appear first.

Revoking sessions 🔗

A session ends in one of three ways:

• Expiry. The access token lapses at its lifetime. Activity does not extend it.
• Logout from the Sessions tab. The session’s token is revoked immediately. The next request that presents it fails. The action records the same audit event as deleting a token: <email> revoked token <name> (category token, action delete). The confirmation reads Token "<name>" deleted, because a session is stored as a token.
• Signing out of the app. Signing out ends the browser’s identity session and revokes its stored grant.

Changing your password does not end your other sessions. Layer5 Cloud has no sign-out-everywhere action and no idle timeout setting. To end your other sessions, log each one out from the Sessions tab.

The deleted session cannot be restored. Whoever used it must sign in again.

See Sessions in Layer5 Cloud.

If you suspect your account is compromised 🔗

1. End every session you do not recognize. A creation date you cannot account for means someone else signed in with your credentials.
2. Change your password. Changing the password does not end other sessions, so complete step 1 first and check the list again afterward.
3. Review your API tokens and revoke any you did not create. Tokens never expire and are not sessions, so signing out does not revoke them.
4. If you cannot sign in, ask an Organization Admin or Provider Admin to help recover the account.

Layer5 Cloud has no “sign out everywhere” action. End each session from the list.

How the browser stores a session 🔗

The cookie’s scope depends on how the organization signs users in:

• Platform sign-in provider. The cookie is shared across the platform’s hosts, so one sign-in covers them.
• Organization’s own identity provider, or a custom domain outside the platform’s domain. The cookie is host-only and is never sent to any other host.

See Organizations for how custom domains and identity providers decide where a user signs in.

Sessions and API tokens 🔗

Sessions and API tokens both authenticate as you, and Layer5 Cloud revokes them through the same mechanism. They differ in how they start and how long they live. Tokens and sessions share one store. isOauth=false selects API tokens and isOauth=true selects sessions.

The Tokens tab never lists sessions, and the Sessions tab never lists API tokens.

You see only your own sessions. Sessions are scoped to your user account, not to one organization.

What Layer5 Cloud does not offer 🔗

• No organization-level session policy. Lifetimes are set for the whole deployment.
• No idle timeout setting in the product interface.
• No device, browser, or location detail on a session.
• No action that ends every session at once.

Session endpoints 🔗

Paths sit under /api unless noted. A missing or revoked credential returns 401 with {"message": "user must be logged in to perform this operation"}. When Layer5 Cloud cannot read the revocation record, it refuses the request rather than accept a token it cannot check.

Related Reading

• Identity and Security
• Keychains
• Keys
• Roles
• Default Academy Roles
• Default Organization Roles