Backstage SSO and identity integration guide

Why Backstage SSO is harder than the login button

Your platform team has a Backstage instance, your identity provider is already chosen, and developers still land on a guest session or find two accounts that represent the same person. Sign-in is the point where that goes wrong. To answer the page question directly: every identity provider you enable must map its users to one Backstage identity, and catalog ownership depends on that mapping, because the owners recorded on components, systems and teams are only meaningful if the signed-in user resolves to the same entity that the catalog references.

Backstage ships 19 built-in authentication providers, including GitHub, GitLab, Google, Azure, Okta, Auth0, OneLogin, Bitbucket, Cloudflare Access, AWS ALB, Google IAP and generic OIDC. Choosing the provider and entering its client ID, secret and tenant settings in app-config is the easy part. The provider only proves who the person is. It does not decide which Backstage user entity that person becomes, which groups they belong to, or what they can see. Those decisions live in the sign-in resolver, and they are where most of the effort sits.

Several things make this harder than the login button suggests. Resolver logic has to match a provider identity to a catalog user, usually by email or by a provider-specific subject, and it has to handle people who have two accounts, contractors, renamed users and service accounts that should never sign in as people. Group membership drifts: a team reorganization in the identity provider does not update Backstage until the catalog ingests the change, so ownership and access can lag behind reality. Callback URLs differ per environment, and an OAuth application registered for a development host will fail quietly or redirect to the wrong place in production. Guest access, which is convenient during testing, is often left enabled. The Backstage authentication documentation advises against offering guest access in production.

Backstage is an Apache-2.0 project with no paid edition from the project itself, so no vendor owns the identity design for you. Decide before rollout which claim is the matching key, who owns the resolver code, how groups are ingested and how often, which environments get separate OAuth registrations, and how guest access is disabled and verified. Ask any implementation partner to show these decisions in writing, with a test plan that signs in as several users from each provider, checks the resulting catalog entity and confirms that guest access returns an error in production configuration.

Choosing the sign-in provider and identity model

This table compares the four realistic ways to sign users into Backstage and the choice between syncing identities into the catalog and resolving them at sign-in. Read each row against your own identity estate: the fit column shows when an option makes sense, and the operating cost column shows what your team will maintain after launch.

Option	When it fits	Operating cost to plan for	What to confirm with the vendor or your team
Corporate IdP with a built-in provider (Okta, Microsoft Entra ID)	Your organization already runs one of these as the single source of workforce identity and wants group-based access in Backstage	Group claims must be mapped to catalog groups, token refresh and client secret rotation, and sign-in resolver logic kept aligned with the IdP's user identifiers	Confirm the provider is in the Backstage authentication documentation for your release, which claims and group types your tenant emits, and whether nested groups are included
Google or GitHub sign-in	Smaller organizations or open-source-style teams where accounts are already managed in Google Workspace or GitHub organizations	Mapping organization or domain membership to catalog groups is manual or relies on a separate sync, and offboarding depends on the provider account lifecycle	Confirm which organizations, domains or teams can sign in, how removed members lose access, and whether group data is available to the resolver
Generic OIDC provider	Your IdP has no built-in Backstage provider but supports standard OpenID Connect and issues the claims Backstage needs	Custom configuration and resolver code are owned by your team, and every upgrade to the auth plugin needs a regression check of the sign-in flow	Confirm the issuer metadata URL, supported scopes, the claim that identifies the user, and the group claim format with your identity team
Proxy-based sign-in (Cloudflare Access, AWS ALB, Google IAP)	Sign-in must be enforced at the network edge, or your access policies already live in one of these services	Proxy policy, certificate and session settings sit outside Backstage, and an outage or misconfiguration in the proxy blocks all access to the portal	Confirm the proxy issues the identity headers or token Backstage expects, how sessions expire, and who owns proxy policy changes after launch
Sync users and groups into the catalog	You need groups, ownership and team membership visible in the catalog for ownership fields, notifications and access rules before users sign in	A scheduled ingestion job runs and must be monitored, and stale or removed users persist until the next sync unless deletion handling is configured	Confirm which entity types the ingestion provider creates, how often it runs, and how removed users and groups are marked or deleted
Resolve identity at sign-in time	Your catalog ownership model is small, or group membership is only needed for permission decisions at login	Group membership is read on each sign-in, so an IdP lookup failure or slow response affects login, and catalog owner references may not resolve until the user first signs in	Confirm the resolver can read group membership from the IdP at sign-in, the behavior when that lookup fails, and whether group data is cached

How to wire Backstage sign-in to your identity provider

This sequence connects Backstage sign-in to your identity provider so every user resolves to one catalog identity, with per-environment settings, managed secrets and guest access removed. The result is a portal where your own users sign in, appear in the catalog with their groups, and can be trusted for ownership and permissions.

Register the Backstage application in the identity provider
Your identity administrator creates an OIDC or OAuth application in your IdP (Okta, Microsoft Entra ID, Google, GitHub or a generic OIDC provider) and sets one redirect URI per environment, such as a local development address, a staging host and a production host. Each URI follows the callback path that the Backstage authentication documentation specifies for the chosen provider. Confirm the redirect URI matches the configured base URL character for character, including scheme, host, port and trailing path. The step is done when the application exists in each environment with its client ID recorded and the redirect URIs listed exactly as the app will send them.
Add the auth provider block to app configuration
A platform engineer adds the auth section to the Backstage app-config files, naming the provider, the client ID, the tenant or domain value and the scopes the provider needs. Keep environment-specific values in environment-specific config files so development and production do not share redirect targets. Reference the client secret through an environment variable or secret reference rather than writing it inline. The step closes when the backend starts without configuration errors and the sign-in route for the provider is served, which you can confirm from the backend logs.
Store client secrets outside source control
Place the client secret in your secret store, such as your cloud secret manager, Vault or the Kubernetes secret mechanism your platform already uses, and inject it into the backend at runtime. Remove any copy from config files, pull request history and CI logs, and rotate the secret if one was committed. Confirm with a repository search for the secret value and a review of the deployed environment variables. The step is complete when the secret is absent from the repository and the backend reads it successfully on startup in each environment.
Add a sign-in resolver that maps users to catalog entities
Write or configure a sign-in resolver so each successful authentication returns a single catalog entity reference, typically a user entity named from the directory identity such as the email prefix or the username. The Backstage authentication documentation recommends resolvers that make every provider produce the same identity, so a user who signs in through a second provider lands on the same entity. Test with a known account and check that the resolver returns the expected reference, for example a user entity in the default namespace, before going further. The step closes when that reference matches the user you intended and no duplicate entity is created.
Load users and groups from the catalog source
Configure a catalog provider that ingests users and groups from your IdP directory, or from the source your organization designates as authoritative, and set the schedule for refreshes. Membership changes in the directory should flow into Backstage on the next sync, which is how group-based ownership and access rules stay accurate. Decide which groups matter for the portal, since importing every directory group can clutter ownership pickers. The step is done when a sync completes without errors and the expected users and groups appear in the catalog with their parent and child group relationships.
Disable the guest provider
Remove or disable the guest sign-in provider in the configuration for every environment that serves real users, as the Backstage authentication documentation advises for production. Guest access bypasses the identity provider and the resolver, so leaving it on undermines the group membership and ownership data built in the previous steps. Confirm the guest sign-in option is no longer offered on the sign-in page and that a direct request to the guest route does not issue a session. The step is complete when only your configured provider can establish a session in production.
Test sign-in with a standard user and an administrator
Sign in as one standard user and one administrator, each from a clean browser session, and check the identity shown in the portal. Confirm the user entity matches the expected name, the group memberships shown in the catalog match the directory, and the administrator has the elevated access your permission setup grants. Repeat the test in each environment, since redirect URIs and secrets differ by environment. The step closes when both accounts sign in, resolve to the right catalog entities and show the correct groups, and any mismatch is recorded and fixed before the portal opens to users.
Keep auth configuration in version control through upgrades
Store the auth provider configuration, resolver code and catalog provider settings in version control, with secrets referenced rather than stored, so the setup survives later upgrades. Backstage upgrades move all @backstage packages together using yarn backstage-cli versions:bump, and the Backstage Upgrade Helper shows template changes between versions, so a reviewed change history makes each bump easier to check against your auth behavior. Re-run the sign-in test in each environment after every upgrade. The step is done when a fresh checkout of the repository, with secrets supplied from the store, produces a working sign-in in each environment.

How sign-in resolvers map every provider to one identity

A sign-in resolver is the piece of Backstage auth configuration that turns the identity a provider returns into a Backstage user entity reference. The catalog, the permission framework and ownership checks all key off that reference, so the resolver decides which user a person is inside Backstage. Get it wrong and the portal can treat one employee as two people, or attach the wrong permissions to a session. Before you write any resolver logic, decide which attribute will be the single source of identity for each person, such as the work email from your identity provider or a stable user identifier, and document it.

The Backstage authentication documentation advises configuring sign-in resolvers so that every provider resolves to the same identity. This matters most when you enable more than one provider, for example a corporate IdP for employees and GitHub for contractors or open-source maintainers. If each provider produces its own entity reference for the same person, you get two users, two sets of group memberships and two sets of ownership relationships. Plan a test matrix that signs in with each provider using the same test person and confirms that a single user entity is used. Check the current auth documentation for the exact resolver interface and the helper functions available in your Backstage version, since these details change between releases.

Group membership flows into ownership through the catalog, not directly through sign-in. User and group entities are ingested from your identity provider (or from a catalog provider that reads it), and sign-in resolution links a session to a user entity that already exists or can be created. Decide which groups become owners of components, systems and teams, and confirm the group names in the IdP match the group entity references in the catalog. A mismatch here typically shows up as a user who signs in successfully but sees no owned components, which is a configuration issue rather than an authentication failure.

Stale group data is the main way wrong access happens in this design. If a person leaves a team, changes role or is removed from a group in the IdP, the change only takes effect in Backstage once the catalog ingestion has run again and the resolver and permission checks read the updated data. Ask your team to confirm how often user and group ingestion runs in your deployment, what happens to users who disappear from the source, and whether removed group memberships are cleared or only added. Test this with a real offboarding scenario in a non-production environment before relying on it for access decisions.

Plan for resolver failures as a security concern. A resolver that cannot find a matching user should fail closed rather than create an unexpected account, and the logs should record the provider, the identifier used and the reason for the failure. Keep guest access disabled in production, as the authentication documentation advises, and confirm that no fallback path bypasses the resolver. Write down who owns the resolver code, who reviews changes to it and which tests must pass before a provider is added or an attribute mapping changes.

How callback URLs, secrets and access change by environment

A single development or test instance usually runs on a laptop, a shared test host or a temporary URL. Sign-in still goes through the identity provider, so the callback URL registered with the provider must match the address the browser actually uses. Teams often register only the production callback and then wonder why local sign-in fails, or they leave a temporary tunnel URL registered long after the test ends.

What to configure differently:

Register a separate development callback in the identity provider rather than reusing the production application.
Keep the base URL and the callback path in the app configuration consistent with the temporary address.
Use development-only client credentials, stored outside the shared repository.
Confirm whether guest access is enabled here and keep it out of any shared or production-like instance.
Remove or expire temporary callback registrations when the test host is retired.

What breaks if it is missed: sign-in redirects to an unregistered address, developers copy production secrets into local files, or a forgotten test callback remains valid in the identity provider.

Confirm with the client: which identity provider tenant or application the test instance uses, who owns its registration, and whether test users are real staff accounts or dedicated test identities.

What drives the effort of Backstage SSO work

This table lists the factors that move the effort of a Backstage sign-in and identity project, with a way to reduce each one. Use it to see which factors apply to your environment before you ask for a fixed-scope quote. The main takeaway is that a single authoritative identity provider and a naming standard for groups usually shrink the work more than any other change.

Driver	Why it changes effort	How to keep it down
Number of identity sources	Each provider needs its own sign-in configuration, callback registration and resolver behavior. Several providers that describe the same people multiply testing.	Make one authoritative IdP the sign-in source and treat other sources as read-only inputs to the catalog.
Groups and nested group structures	Every group that maps to a Backstage owner needs a rule, and nested groups add inheritance questions about which owner wins.	Adopt a group naming standard and map only groups that own catalog entities, not every group in the directory.
Environments with separate registrations	Each environment (for example development, staging and production) usually needs its own app registration, redirect URLs and secrets.	Template the registration settings and keep environment differences in configuration, not code.
Existing user records to merge	Users who already exist in the catalog or database from earlier imports must be matched to the sign-in identity without creating duplicates.	Agree the matching key (such as a stable user identifier or verified email) before cutover and run a dry-run report.
Custom resolver logic	Stock resolvers handle common cases. Edge cases such as contractors, shared accounts or missing email claims need custom code that must be tested and maintained through upgrades.	Use one resolver pattern for all providers and keep custom rules in a single reviewed module.
Audit evidence for access changes	Assessors may ask who granted access, when group membership changed and how removals were verified. Producing that evidence needs logging and a documented procedure.	Define the required evidence first, such as which log fields and exports are retained and where, then build only that.
Guest access removal across instances	Guest or default sign-in left on in any instance creates an unmanaged access path. Removing it means checking every deployed instance and pipeline.	Confirm the target list of instances and disable guest access through the same configuration in all of them, then verify each one.
What a fixed-scope quote should name	A quote is only comparable when it states which providers, environments, group rules, merge scope and evidence outputs are included.	Ask for the written scope to list each driver above with the agreed count, plus exclusions and the client tasks.
What the buyer should provide	Work stalls when access or data arrives late. Identity admin rights and group data are the usual dependencies.	Provide IdP admin access for app registrations, a group export with owners, a sample of existing user records and a named approver for access rules.

Removing guest access and locking down sign-in

Once Backstage sign-in works, the remaining risk sits in what the portal accepts and who can change it. The controls below cover guest access, the identity provider applications behind sign-in, the secrets and redirect targets they depend on, and the group mappings that decide who owns catalog entries and holds admin roles. Permission policy and service-to-service authentication are covered separately in the security hardening topic.

Disable guest access in production

Backstage offers a guest sign-in path that is useful in local development but should not be reachable in production. Its authentication documentation advises against offering guest access in production. Confirm the guest provider is absent from the production app configuration, then test from an unauthenticated browser session and from direct API calls to the backend to verify that no unauthenticated route returns catalog data or session tokens.

Restrict who changes identity provider apps

Each provider such as Okta, Microsoft Entra, Google or GitHub holds an application or OAuth client that defines what Backstage can ask for and which users can sign in. Limit the people who can create, edit or reassign these applications to a small named group, and require a second reviewer for changes to scopes, allowed users or tenant settings. Record who changed each application and when.

Rotate client secrets on a documented schedule

The client secret that Backstage uses to exchange authorization codes is a long-lived credential. Write a rotation procedure that names the owner, the secret store entry, the order of steps (issue new secret, deploy, verify sign-in, revoke old secret) and the rollback path. Confirm with your identity provider whether two secrets can be active at once, because that determines whether rotation can happen without a sign-in outage.

Limit groups that grant ownership and admin

Sign-in resolvers and group ingestion decide which identity provider groups become catalog owners and which users receive admin roles. Map only the groups that are meant to own catalog entities, and exclude broad directory groups such as all staff or all engineers. Review the mapping whenever a directory group is created or renamed, because a new group that matches an existing rule can silently gain ownership rights.

Keep redirect URIs to known hosts

The OAuth redirect URI tells the identity provider where to send the user after sign-in, and an overly broad or stale entry can route authorization codes to a host you do not control. Register only the exact callback URLs for each Backstage environment, avoid wildcard hosts and leftover entries from test deployments, and check the list after every hostname change or domain move.

Log and review sign-in failures

Repeated failed sign-ins, rejected tokens and resolver errors can show a misconfigured provider, an expired secret or an attempt to reach the portal without the right account. Route authentication errors from the Backstage backend and the identity provider's sign-in log to your existing monitoring, set an owner for review, and define which patterns trigger investigation. Confirm the log fields your provider exposes before you rely on them.

How to test Backstage SSO and confirm it fails safely

Test the sign-in path before anyone outside the platform team relies on it. A working login is only part of the result. The test plan has to show that each identity provider lands on one user entity, that group changes in the identity provider reach the catalog, that removing a user stops new sessions, and that guest access is not reachable in production. Run these checks in the test environment first, with the same provider configuration, sign-in resolvers and catalog ingestion settings you intend to promote. Write down the exact provider tenant, application registration and Backstage config version used for each run, because a test against a different tenant proves little about production. Start with sign-in. Sign in once with each supported provider you plan to enable, such as Okta, Microsoft, Google, GitHub or a generic OIDC provider, and confirm that every login resolves to the same user entity in the catalog. Use one person who has accounts in two providers to check the identity linking. If the same human appears as two users, the sign-in resolver is wrong, and the group and ownership data built on top of it will also be wrong. Next, change a group membership in the identity provider, wait for the next catalog ingestion run, and confirm the change appears on the user entity. Then remove a test user from the identity provider and confirm that a new sign-in is refused. Existing sessions may remain until they expire, so record how long that window is in your configuration and confirm it with the team that owns session policy. The failure tests matter as much as the success path. Run four cases in the test environment. First, set an invalid client secret and confirm sign-in fails with an error that names the authentication step, without exposing the secret. Second, use a wrong redirect URI and confirm the provider rejects the request and Backstage shows a clear error rather than a blank page. Third, simulate an identity provider outage, for example by blocking egress to the provider, and confirm users are denied with a message that they can retry later. Fourth, sign in as a user with no group membership and confirm the resolver either denies access or creates a user with no permissions, according to the policy you agreed. In each case, the expected result is denial with a clear error. A safe failure is not a fallback to guest access, a shared account or a silently created user with broad rights. If any failure lands in guest access, stop the rollout and fix the configuration. For production, add one check that is easy to skip: confirm that guest access returns an error. Attempt a guest sign-in against the production URL and record the response. Keep the test results in a dated record: the test case, environment, configuration version, expected result, actual result, and the name of the tester. Attach this record to the change ticket so auditors and reviewers can see what was verified and when. This record is evidence of your own testing. It is not an audit report, and an independent assessor will decide whether it satisfies your control requirements. Ask your compliance lead which evidence format they expect before the first run.

What to monitor, rotate and document after go-live

Sign-in works on day one, but identity integrations drift. Credentials expire, group membership changes, and Backstage upgrades can alter authentication behavior. The items below cover what to watch, what to rotate, what to keep in version control, and what the handover documentation must record.

Monitor failed sign-ins and resolver errors

Review Backstage backend logs for failed provider callbacks, token validation errors and sign-in resolver failures. A resolver that cannot match an identity to a catalog user usually surfaces as a sign-in error for one provider while others keep working. Set alerts on these error patterns, and record which log fields identify the provider, the user reference and the failing resolver step so on-call engineers can triage without reading source code.

Schedule catalog user and group checks

Run a recurring check that confirms users and groups ingested into the software catalog match the current state of your identity provider. Look for missing users, stale group memberships, and groups that were renamed or deleted upstream. Because ingestion runs on a schedule, a failed run can leave the catalog stale without any visible sign-in failure, so the check should compare counts and sample records against the source and report differences to the platform team.

Track client secret and certificate expiry

Each OIDC or OAuth registration in your identity provider carries a client secret or certificate with an expiry date. Record the expiry for every environment, assign an owner, and set reminders well ahead of the date. Confirm the rotation procedure in a non-production environment first, including how the new value reaches the Backstage configuration and secret store, and whether old and new credentials can overlap during the change.

Review IdP groups used for ownership

When Backstage derives ownership or access from identity provider groups, membership changes in the IdP change who owns catalog entities and who sees which templates. Review the groups that feed ownership on a fixed cadence with the people who manage them. Confirm that offboarded staff lose access in the portal through the next ingestion cycle, and that shared or service groups do not grant owner rights by accident.

Keep auth configuration in version control

Store provider settings, resolver code, group mapping rules and permission policies in the same repository as the Backstage app, reviewed through normal pull requests. Auth configuration that lives only in environment variables or a console is easy to change without review and hard to reproduce. Versioned configuration also lets you diff what a Backstage version bump changes, so an upgrade does not silently alter how users sign in.

Review identity configuration on every upgrade

The Backstage versioning policy says high and critical severity vulnerabilities are backported to releases from the last 6 months where feasible, and other security fixes may be backported. Security fixes can therefore arrive as routine upgrades, so identity configuration must be re-checked each time you move to a new release. Confirm sign-in, resolver output and group ingestion in staging after every bump, using the Upgrade Helper to review template changes before applying them.

Document the handover package

The handover should contain provider registrations for each environment with redirect URIs and owners, the resolver logic with examples of each identity match, the group mapping rules, the decision on guest access and the reason for it, and the test evidence from staging and production sign-in checks. Keep the document next to the code so it is updated when the configuration changes, and have the people who will operate the integration review it before go-live.

Backstage SSO questions buyers and engineers ask before hiring help

What does Backstage SSO integration cost and what drives the price?

Cost depends on the written scope, not on a standard package. The main components are discovery, provider configuration, sign-in resolver code, group and user ingestion into the catalog, testing in each environment, and handover documentation. Setup work is largely one-time, while recurring costs sit with your team: identity provider administration, group changes, and upgrade testing. The biggest cost drivers are the number of identity providers, how complex your group model is, how many environments need sign-in, whether custom resolver logic is required, and whether guest access must be retired. DeployOpen does not publish a price list. Ask for a quote that lists each component, states what is one-time and what recurs, and names what the client must supply.

How long does a Backstage SSO project usually take to complete?

The duration depends on the drivers of the work, and the fixed-scope quote states the timeline for your case. Each identity provider you add, each environment (development, staging, production), and each group rule adds testing and review. A single provider with a clear group model moves faster than several providers that must resolve to one identity. Delays usually come from waiting on identity provider admin access, unclear decision owners, or undocumented group membership. Guest access removal can also extend the schedule if teams rely on it. Ask the provider to show which phases the timeline covers, which client actions gate each phase, and how verification in staging is scheduled before production cutover.

What must our team provide before outside help starts on Backstage sign-in?

Four inputs unblock most engagements. First, administrator access to the identity provider, or a named administrator who can make changes during the project, including app registration and claim or group settings. Second, a written description of your group structure, with the groups that should grant access to the catalog and the ones that should not. Third, a list of target environments with their URLs and hosting locations. Fourth, a named decision owner who can approve resolver rules, access scope and the cutover date. It also helps to share your current Backstage configuration and any existing guest access or shared accounts, so the team can plan their removal. Confirm each item in writing before the work starts.

Can one internal engineer set up Backstage SSO without outside help?

Yes, one engineer can usually do it alone when the project has one identity provider and a clear group model. Backstage ships with built-in authentication providers, including Okta, Microsoft Azure, Google, GitHub and generic OIDC, so the configuration is a known pattern. The engineer should verify the work in steps. Confirm that each sign-in resolves to the same user entity. Check that group membership ingests into the catalog as expected. Test with a user who should be denied and confirm they cannot sign in. Review session behavior after logout. Repeat the checks in every environment before production. Engineers who lack experience with OIDC claims or resolver code often benefit from a short external review of the resolver.

Is it safe to remove guest access from a live Backstage instance?

It can be done safely with a staged plan, but no outcome can be promised in advance. The Backstage authentication documentation advises against offering guest access in production, so removal is the expected direction. Start by inventorying who uses guest sign-in and which catalog entities or templates depend on it. Confirm that every real user can sign in through the chosen provider in staging. Plan the production change for a window where you can watch sign-in errors, and keep a documented rollback to the previous configuration. Communicate the change to users and owners before it happens. Check afterward that ownership data still maps correctly, because entities created under guest identities may need reassignment.

What changes in the sign-in setup after a Backstage upgrade?

Upgrades can change configuration files, package versions and authentication code, so the sign-in setup needs retesting after every bump. Backstage packages move together using the versions bump command in the Backstage CLI, and the Backstage Upgrade Helper shows template changes between versions. The Backstage project publishes a main release line monthly and a next line weekly, so the cadence of change is steady. After an upgrade, check provider configuration, resolver behavior, group ingestion and session handling in staging before production. Also confirm that your Node.js version remains within the supported range for your Backstage release. Plan these checks into your upgrade process rather than treating them as an afterthought.

Does DeployOpen issue an audit or certification for our identity setup?

No. DeployOpen does not issue audit reports, attestations or certifications. Its work is to plan, configure and document the identity setup, and to prepare the configuration records and evidence that an assessment will review. These can include provider settings, group mappings, resolver logic, test results and change records. Independent auditors and certification bodies perform the assessment and decide whether a control is met. If your organization needs an external assessment, ask your auditor which evidence they expect for identity controls, and agree with DeployOpen in writing which artifacts will be delivered. Clarify this in the scope before work starts so the evidence matches what the assessor will request.

Which identity providers does Backstage support for sign-in?

Backstage includes 19 built-in authentication providers, according to the Backstage authentication documentation. The list includes GitHub, GitLab, Google, Azure, Okta, Auth0, OneLogin, Bitbucket, Cloudflare Access, AWS ALB, Google IAP and generic OIDC. Built-in support still requires configuration, resolver logic and group ingestion that match your organization's identity model. Confirm that your specific provider tenant, plan and claim settings behave as expected during discovery, because provider features vary by vendor and edition. If your provider is not on the list, a generic OIDC setup may still fit, but its claims and group handling need to be verified before the design is approved.

How DeployOpen scopes, builds and hands over Backstage SSO

DeployOpen plans, implements and documents Backstage sign-in inside your own infrastructure, so the identity provider, resolvers, catalog ingestion and guest access removal are agreed in writing before work starts. Engagements are fixed-scope, and ongoing support is available as a retainer once the portal is live.

How we scope

We confirm which identity provider you use, such as Okta, Microsoft, Google, GitHub or generic OIDC, and who will administer it
We agree in writing which sign-in resolvers map each provider to one consistent user identity in the catalog
We record how users and groups will be ingested into the catalog and which owners each group maps to

How we build

We configure each authentication provider in the Backstage app config and wire it to your identity tenant in a non-production environment first
We write and test sign-in resolvers so every provider resolves to the same identity, including edge cases for duplicate or missing accounts
We remove guest access from the production configuration and verify that unauthenticated users cannot reach catalog or plugin routes

How we hand over

We deliver a written record of provider settings, resolver logic, group mappings and secrets locations, without storing credentials in the document
We run a sign-in test plan with your team covering each provider, group-based ownership and access denial for unauthenticated requests
We walk your platform engineers through the resolver code and the steps to add a new provider or group

How we support

Ongoing support, upgrades and testing can be covered by a retainer agreed in writing after go-live
Upgrade work keeps authentication packages aligned with the other @backstage packages so sign-in does not break at release time
We confirm the support boundary, response expectations and included upgrades in the retainer scope before signing

Backstage SSO and identity integration