Google Auth Backstage Plugin
You set up the google auth backstage plugin by linking Google OAuth keys to your portal backend. Next, you match user emails to catalog records so engineers can log in. Platform teams often use this setup to manage portal sign-in with work accounts. Still, they often give every signed-in user the same broad role. When roles are too broad, any team member can trigger sensitive actions or read private data. How the google auth backstage plugin works The sign-in flow starts when a user clicks t
Backstage Security Plugins + Network Location-Based Auth: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up the google auth backstage plugin by linking Google OAuth keys to your portal backend. Next, you match user emails to catalog records so engineers can log in.
Platform teams often use this setup to manage portal sign-in with work accounts. Still, they often give every signed-in user the same broad role. When roles are too broad, any team member can trigger sensitive actions or read private data.
How the google auth backstage plugin works
The sign-in flow starts when a user clicks the login button in the portal UI. The app sends the user to Google to check their work email and password. You must first create OAuth client keys inside your Google Cloud project. You also set an allowed callback URL so Google knows where to send the user back.
After Google checks the user, it sends a token back to the portal backend. The backend reads the email address and profile info from that token. Then, a sign-in resolver matches that email to a user entity in the software catalog. If the user does not exist in the catalog, the login fails right away.
Once the resolver finds a match, it issues a portal token for that specific user. This portal token includes group ownership claims based on the team catalog data. The frontend stores this token and sends it along with future requests to backend plugins.
Managing catalog identity mapping and group roles
A common problem happens when Google emails do not match the catalog user records. Teams fix this by syncing Google Workspace groups directly into the portal catalog on a schedule. This sync keeps team memberships up to date when engineers join or leave the company.
You can also write custom sign-in rules to check the email domain before granting entry. This step stops personal Gmail accounts from logging into an internal company portal. Even with clean group syncs, catalog roles remain static after the user logs in.
Backstage Security Plugins + Network Location-Based Auth: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Static roles mean a user keeps the same high-level permissions all day long. If an engineer needs to fix one broken service, they often get full admin rights everywhere. Teams need a better way to control actions after the initial login step finishes.
What native sign-in solves and what it leaves open
The native sign-in setup does a great job of proving who a user is. It links a real person and their work email to a known team in your catalog. It also blocks outside users from viewing your internal service catalog and docs.
Still, sign-in only decides who enters the portal at the start of the day. It does not check what individual database queries, shell commands, or API calls do in flight. Once a plugin or tool runs an action, the login module has no visibility into the payload.
For example, a backend tool might connect to a live database using a shared service key. Every engineer in that group shares the exact same database role through the portal. You cannot tell which user ran a drop table query or read customer phone numbers. To close this gap, teams need controls that check each command and mask sensitive fields like emails or card numbers in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why does login fail even when the Google account is valid?
The portal requires a matching user record in the software catalog by default. If the sign-in resolver cannot find the email in the catalog, it rejects the login.
Can we restrict sign-in to our company email domain?
Yes, you can restrict access inside your Google Cloud OAuth consent screen settings. You can also set the portal sign-in resolver to reject outside email domains.
Does the plugin control what users do inside connected databases?
No, the plugin only checks user identity when they log into the portal interface. It does not inspect or limit the queries sent to backend databases or servers.