Backstage Authentication
You set up backstage authentication by linking an external identity provider to your portal backend. The backend checks user tokens and maps each login to a catalog user entity. Platform teams often start with a basic sign-in setup so developers can test the portal. If teams leave guest roles open or grant broad permissions, anyone can trigger sensitive actions. How backstage authentication works under the hood The portal does not store user passwords or manage user accounts on its own. Inste
Multi-Factor Authentication (MFA) + Backstage Security Plugins: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up backstage authentication by linking an external identity provider to your portal backend. The backend checks user tokens and maps each login to a catalog user entity. Platform teams often start with a basic sign-in setup so developers can test the portal. If teams leave guest roles open or grant broad permissions, anyone can trigger sensitive actions.
How backstage authentication works under the hood
The portal does not store user passwords or manage user accounts on its own. Instead, it relies on external sign-in services like GitHub, Google, or corporate single sign-on. When a developer opens the app, the frontend sends them to the identity provider. The identity provider checks who the person is and returns a signed proof of identity.
Next, the sign-in resolver inside the portal backend takes over the login flow. This resolver matches the external profile to a specific user record in the software catalog. For example, it can match an email address to a catalog user entry. It also checks which team groups that person belongs to inside the catalog.
Once the resolver finds a match, the backend issues its own internal session token. The browser stores this token and sends it with every request to portal plugins. Plugins read the user identity and group list from this token to check permissions. If a user is not in the catalog, the resolver can reject the login.
Managing catalog entities and group roles
A clean sign-in flow depends on accurate user and group records in your catalog. Most teams sync their company directory with the portal catalog on a set schedule. When a new engineer joins a team, the directory sync adds their profile and group. The sign-in resolver then knows which team role to attach at login time.
You should disable the guest login provider before you move the portal to production. Guest access lets anyone enter the portal without tying actions to a real person. You should also require that every person exists in the catalog before issuing a token. This rule stops unknown accounts from viewing internal services or running portal templates.
The permission framework in the portal uses these group memberships to gate plugin actions. You can write rules that allow only the database team to delete catalog items. Other rules can let any developer read service docs while blocking changes to production templates. Tying rules to catalog groups keeps role management simple as your company grows.
Multi-Factor Authentication (MFA) + Backstage Security Plugins: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native portal login solves and where gaps remain
Setting up sign-in providers and resolvers solves identity checks inside the developer portal UI. Your team knows which engineer logged in and which catalog pages they can view. The portal can also hide software templates or plugin buttons based on team roles. This keeps the catalog organized and stops unauthorized clicks inside the web app.
Still, portal login only controls who enters the catalog and clicks UI buttons. It does not control what happens when engineers run commands against databases or cloud servers. Portal plugins often use shared static keys to talk to external systems in the background. Anyone who triggers that plugin runs actions under the same broad backend service account.
Also, developers still leave the portal to run database queries or terminal commands directly. Native portal login cannot inspect individual SQL statements or CLI commands during those direct sessions. It cannot mask sensitive fields like emails, phone numbers, card numbers, or national IDs in query results. Teams need runtime controls that inspect every query and command across their real systems.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why does my login work while catalog plugins still deny my requests?
Your identity provider confirmed who you are, but the sign-in resolver missed your catalog group. Check that your user record exists in the catalog and links to your team entity.
Should we allow login for users who are not in the software catalog?
No, you should require a matching catalog entity for every person who logs in. Allowing unmapped users makes it hard to assign group roles or track user actions.
How do backend plugins check who sent a request inside the portal?
The frontend attaches the internal portal token to every call it makes to backend plugins. The backend plugin checks the token signature and reads the user and group claims inside.