--- title: "Reuse RShift Sites workspace identity in your app" description: "Let apps you build for your team recognize the signed-in RShift Sites user automatically, without a separate login flow." image: "https://help.rshift.com/og.svg" --- > Documentation Index > Fetch the complete documentation index at: https://help.rshift.com/llms.txt > Use this file to discover all available pages before exploring further. # Reuse RShift Sites workspace identity in your app 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](/sites/features/business/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](/sites/features/saml-sso/) | 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](/sites/features/workspace-identity/) 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](#when-to-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](/sites/features/privacy-and-security-settings/#require-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. > **Danger** > > Do not mix workspace identity reuse with a traditional app sign-in flow unless you intentionally design a hybrid app. For most apps, choose one auth model: RShift Sites identity for workspace-member apps, or traditional app authentication for public and customer-facing apps. ## Prerequisites * A **Business** or **Enterprise** workspace. * A newer RShift Sites project that uses [TanStack Start](https://lovable.dev/blog/building-apps-using-tanstack-start). Older React + Vite projects are not eligible, but you can [upgrade an older project to TanStack Start](/sites/features/upgrade-to-tanstack-start/) to make it eligible. * **RShift Sites workspace identity** allowed in your workspace's [App login methods](https://lovable.dev/settings/privacy-security) policy. It is allowed by default. If you are not sure which stack your project uses, ask RShift Sites: ```text 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](https://lovable.dev/settings/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: ```text 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. ``` ```text 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. ``` > **Tip** > > Be explicit about which login model you want. If you only say "add login", RShift Sites may build a traditional sign-up flow with email or Google instead. Say that you want to use the signed-in RShift Sites user, like the prompts above do. **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. > **Tip** > > Identity works in preview. You do not need to publish the app to test it. ## Turning workspace identity reuse off * **For the whole workspace**: a workspace admin or owner blocks **RShift Sites workspace identity** in [Privacy & security](https://lovable.dev/settings/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](/sites/features/google-auth/), or [SAML SSO for Cloud app users](/sites/features/saml-sso/). * 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](/sites/features/google-auth/), [email sign-in](/sites/features/email-auth/), or [SAML SSO for Cloud app users](/sites/features/saml-sso/). ## 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?](#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](/sites/introduction/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](https://lovable.dev/blog/building-apps-using-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](/sites/features/upgrade-to-tanstack-start/). * **RShift Sites workspace identity** is allowed in [Privacy & security](https://lovable.dev/settings/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](/sites/features/privacy-and-security-settings/#require-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: ```text 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. ## Related topics - [Manage workspace identity and user provisioning](/sites/features/workspace-identity/) - [Set up workspace single sign-on (SSO)](/sites/features/business/sso/) - [Add SAML single sign-on to your app](/sites/features/saml-sso/) - [Privacy & security settings](/sites/features/privacy-and-security-settings/) - [Add Google authentication to your app](/sites/features/google-auth/) Source: https://help.rshift.com/sites/features/lovable-workspace-identity-reuse/index.mdx