The application owner remains accountable for access design, role mapping, and policy enforcement. A third-party provider can supply identity assertions and session tokens, but the organisation must decide how those claims translate into database access, application permissions, and enterprise login requirements. Governance does not transfer with the integration.
Why This Matters for Security Teams
When a third-party provider handles sign-in or issues session tokens, it is easy to assume authentication responsibility has moved with the integration. It has not. The provider may validate identity, but the application owner still decides what that identity can do, which claims are trusted, and how database and application permissions are enforced. That distinction is central to accountability, especially when third-party assertions are mapped into privileged access.
This is where security teams often get tripped up: authentication and authorisation are treated as a vendor feature, while the real risk sits in the organisation’s policy design. NHI Management Group research shows that 92% of organisations expose NHIs to third parties, which makes provider trust boundaries a practical governance issue, not a theoretical one. The OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce that access control remains an owner responsibility, even when identity assertions are outsourced.
In practice, many security teams encounter over-permissioned access only after a provider-issued token has already been accepted by downstream systems.
How It Works in Practice
With Supabase or a similar third-party identity layer, the provider typically handles authentication events such as credential validation, token issuance, and session management. The organisation remains accountable for how those claims are consumed. That means defining what each role, claim, or group membership actually unlocks in the application, database, and API layer. If a token says a user is authenticated, that does not automatically mean the user should have write access, admin access, or access to every tenant.
Practitioners should separate identity proof from authorisation logic. The provider can confirm who or what authenticated, but the application must decide whether that identity is allowed to perform the requested action. Current guidance suggests using explicit policy mapping for roles and claims rather than assuming provider defaults are sufficient. The ISO/IEC 27001:2022 Information Security Management model is helpful here because it treats access control as a managed control domain, not a delegated side effect.
- Define which identity claims are trusted, and reject anything not required for access decisions.
- Map provider groups or attributes to internal roles with least privilege, not one-to-one administrative convenience.
- Enforce database policies separately from login success, especially for row-level or tenant-level access.
- Require enterprise login rules, such as MFA or conditional access, where risk justifies it.
- Review token lifetime, revocation, and refresh behaviour so stale sessions do not outlive policy changes.
The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a reminder that identity trust without access governance creates blind spots. These controls tend to break down in multi-tenant applications with shared schemas because provider claims rarely encode enough context for safe per-record authorisation.
Common Variations and Edge Cases
Tighter identity integration often reduces friction for users, but it also increases the burden on access design, requiring organisations to balance convenience against enforceable policy. The hardest cases are not simple login flows; they are delegated admin models, partner access, service-to-service authentication, and applications that mix human and non-human identities under one provider.
There is no universal standard for this yet, but best practice is evolving toward explicit separation of authentication, authorisation, and governance ownership. If Supabase or another provider supports secure identity proofing, that still does not answer who approves privileged access, who reviews role drift, or who owns incident response when claims are abused. Those decisions stay with the application and business owner, not the identity platform.
Security teams should also watch for hidden dependencies such as password reset flows, API keys, and database credentials that bypass the provider entirely. In those situations, a clean SSO design can coexist with weak back-end trust boundaries. NHI Management Group’s Klue OAuth Supply Chain Breach and 52 NHI Breaches Analysis both illustrate how delegated trust becomes a breach path when ownership is unclear.
Related resources from NHI Mgmt Group
- Who is accountable for email authentication controls when an organisation uses its own provider for transactional messages?
- Who is accountable for the security of third-party integrations when business teams can adopt apps directly?
- Who is accountable when a healthcare organisation uses a non compliant signature workflow for protected health information?
- Who should be accountable for enforcing context based access decisions across internal systems and third party tools?
