When you build an internal tool in RShift Sites, the people who use it are usually your own teammates, and they already sign in to RShift Sites every day. Workspace identity reuse lets your app treat that existing sign-in as its login: the app knows who is visiting (their name, email, and RShift Sites user ID) without showing a login page or asking anyone to create another account.
It works no matter how someone signs in to RShift Sites: workspace SSO, Google, or email. The feature is available on Business and Enterprise plans.
Which identity feature do you need?
RShift Sites has three features that sound alike but do different jobs. If you are not sure this page is the right one, start here:
| Feature | What it controls | Who it affects |
|---|---|---|
| RShift Sites workspace identity reuse (this page) | Whether apps you build can recognize the workspace member who is already signed in to RShift Sites | Your workspace members using apps your team builds |
| Workspace SSO | How your team signs in to RShift Sites itself, through your identity provider | Workspace members signing in to RShift Sites |
| SAML SSO for apps | How external end users of a published app on the built-in backend (Cloud) sign in with their own company credentials | Your app’s outside users |
A simple way to keep them apart: the Identity settings decide how people get into RShift Sites. Workspace identity reuse decides what your apps can know about people who are already in. Neither requires the other: identity reuse works even if your team signs in to RShift Sites with Google or email, and you do not need workspace SSO configured.
Why use workspace identity reuse
Identity reuse fits when everyone who uses your app is already in your RShift Sites workspace. Without it, you would need to build and maintain a second login system, and your teammates would sign in twice: once to RShift Sites, and once to your app. With it, the app already knows the current user.
| Use case | Example | Why identity reuse fits |
|---|---|---|
| Internal admin tool | A billing review dashboard for your operations team | Team members already sign in to RShift Sites, so the app can identify them without another login page |
| Employee portal | A workspace-only PTO request app | The app can show each user their own requests and route approvals by RShift Sites identity |
| Workspace reporting | A dashboard that filters activity by the signed-in team member | The app can personalize views based on the current RShift Sites user |
| Per-user data apps | A notes or tasks app where each member sees only their own rows | Your app can use the RShift Sites identity to personalize data access |
For customer-facing apps, public signup flows, or apps where users do not have RShift Sites accounts, use traditional app authentication instead.
How workspace identity reuse works
When a signed-in user opens the preview or the published app, RShift Sites creates a short-lived identity token for that project and user, and passes it along with the app request. Helper code that RShift Sites generates in your app verifies the token and exposes the current user to the rest of your app code.
RShift Sites strips any identity information that visitors send themselves before attaching its own signed token, so a visitor cannot impersonate someone else by faking an identity.
Who gets recognized
The app recognizes people who are signed in to RShift Sites and have access to the project. Everyone else, including anonymous visitors and people who can only view the published app, gets no identity: the helper returns no user, and your app decides what they see, such as a guest view or an access-denied message.
If the workspace requires two-factor authentication, members who haven’t set up 2FA also get no identity until they enroll. They can still open the app, but the app does not know who they are.
What your app can read
- The signed-in user’s RShift Sites user ID.
- The user’s display name, when available.
- The user’s email address, when available.
Do you need the built-in backend?
No. Workspace identity reuse works in any eligible project, with or without the built-in backend (Cloud). Reading the current user’s name or email needs no backend at all.
You need the backend when the app should store per-user data: for example, a task tracker where each member sees only their own tasks. RShift Sites passes the signed-in identity to your Cloud backend so the database can enforce per-user access.
Prerequisites
- A Business or Enterprise workspace.
- A newer RShift Sites project that uses TanStack Start. Older React + Vite projects are not eligible, but you can upgrade an older project to TanStack Start to make it eligible.
- RShift Sites workspace identity allowed in your workspace’s App login methods policy. It is allowed by default.
If you are not sure which stack your project uses, ask RShift Sites:
What stack is this project on?Set up workspace identity reuse
Setup happens at two levels, usually by two different people:
- Workspace level: a workspace admin or owner decides whether apps in the workspace may use workspace identity at all. This is a one-time policy decision, and it is allowed by default.
- App level: the project editor asks RShift Sites to use the signed-in user in a specific app. Nothing uses the identity until you ask for it. There is no per-project setting to turn on or off.
Workspace setup (admins and owners)
Workspace identity is allowed by default, so in most workspaces there is nothing to do here. To confirm or change the policy:
Open App login methods
Open Privacy & security (Settings → Security → Privacy & security), then select Configure under App login methods.
Check RShift Sites workspace identity
The RShift Sites workspace identity entry should show Allowed.
Blocking a method locks it for every project in the workspace. The change takes effect immediately. This policy only affects apps your team builds. It does not change how workspace members sign in to RShift Sites.
App setup (project editors)
Ask RShift Sites to use the signed-in user
In your project, describe the identity behavior you want. RShift Sites makes the app changes needed to use the signed-in identity. For example:
Use RShift Sites workspace identity to show the signed-in user's name and email in the header. If no user is available, show a signed-out state. Build an internal task tracker where each signed-in workspace member only sees tasks assigned to them. Use RShift Sites Cloud for per-user data access.Test it in preview
Open the preview while signed in to RShift Sites. Wherever your app displays the current user, you should see your own details. With the header prompt above, the header greets you with your own name and email instead of showing a login button.
To test what other people see, ask a teammate with access to the project to open the app. They see their own name, not yours. To test the signed-out experience, open the published app in a private browser window. Without a RShift Sites session, the app shows the guest or signed-out state you asked for.
Turning workspace identity reuse off
- For the whole workspace: a workspace admin or owner blocks RShift Sites workspace identity in Privacy & security (Settings → Security → Privacy & security → App login methods). This applies to every project immediately and cannot be changed from a project.
- For a single app: ask RShift Sites to remove it, for example:
Stop using workspace identity in this app and show a public landing page instead.
When to use traditional app authentication instead
Use traditional app authentication when:
- Your app is customer-facing or public.
- Users should create accounts inside the app.
- Users may not have RShift Sites accounts.
- You need app-specific login methods such as email/password, magic links, Google sign-in, or SAML SSO for Cloud app users.
- You need app-owned user accounts, signup flows, or user management that is separate from RShift Sites workspace membership.
In those cases, ask RShift Sites to add the sign-in method you need, such as Google authentication, email sign-in, or SAML SSO for Cloud app users.
FAQ
Is workspace identity reuse the same as workspace SSO?
No. Workspace SSO controls how your team signs in to RShift Sites. Workspace identity reuse lets an app you build read the RShift Sites user who is already signed in. See Which identity feature do you need?
Do I need workspace SSO configured to use this?
No. The identity is the signed-in RShift Sites account, regardless of whether the user signed in with workspace SSO, Google, email, or another supported method.
Do I need the built-in backend?
No. Reading the current user works in any eligible project. You only need the built-in backend (Cloud) when the app stores per-user data.
Can people without access to my project use this identity?
No. Only signed-in RShift Sites users with access to the project get an identity. Everyone else is treated as anonymous, including public visitors and workspace members without access to the project. Use traditional app authentication if public or customer users need accounts.
Does this consume extra credits?
No, workspace identity reuse has no separate cost. Any built-in database, storage, hosting, or AI usage in the app follows normal credits and usage rules.
Troubleshooting
I do not see RShift Sites workspace identity in App login methods
The App login methods dialog shows the entry when the feature is available for your workspace. Confirm your workspace is on a Business or Enterprise plan.
My project cannot use workspace identity
Workspace identity reuse needs all three of the following. Check each one:
- Your project runs on TanStack Start. Some older projects use an earlier stack and are not eligible. If you are not sure, ask RShift Sites:
What stack is this project on?If your project is on the older stack, upgrade it to TanStack Start. - RShift Sites workspace identity is allowed in Privacy & security (Settings → Security → Privacy & security → App login methods).
- Your workspace is on a Business or Enterprise plan.
The app shows no signed-in user
Open the preview while signed in to RShift Sites, and make sure your account has access to the project itself, not only to the published app. If your workspace requires two-factor authentication, set up 2FA on your account: members without it get no identity. If your app supports anonymous visits, make sure it handles the no-user state clearly.
RShift Sites added a login page instead of using my identity
Ask RShift Sites to use the signed-in RShift Sites user as the app identity. For example:
Use RShift Sites workspace identity for this internal app. Do not add a separate email or Google login flow.My Cloud data does not recognize the user
Ask RShift Sites to connect the signed-in identity to your Cloud data access. Avoid mixing this setup with a separate app sign-in flow unless you are intentionally building a hybrid auth model.