A Custom Tab is the browser backed sign in surface used by native Android apps to open an external authentication session. It shares the system browser cookie jar, which preserves existing login state and supports passkeys and password managers. It is preferred over an embedded WebView for identity flows.
Expanded Definition
Custom Tab is the Android-native browser-backed authentication surface that lets an app launch sign in without building its own credential UI. Because it uses the system browser rather than an embedded WebView, it inherits shared cookies, saved sessions, passkeys, and password manager support, which makes it a stronger fit for modern identity journeys. In NHI and IAM terms, it is best understood as a trust boundary decision: the app delegates authentication to the browser ecosystem, but still controls when and how the session returns to the app. Guidance varies slightly across vendors on how much UX control should be retained, yet the security preference is consistent, and it aligns with browser-mediated authentication patterns described in the NIST Cybersecurity Framework 2.0. For NHI programs, this matters because machine-facing and agentic workflows often depend on app-mediated user approval, token handoff, or delegated consent. The most common misapplication is using an embedded WebView for sign in, which occurs when teams prioritise UI consistency over browser-level security features and session integrity.
Examples and Use Cases
Implementing Custom Tab rigorously often introduces a small amount of control loss over the authentication surface, requiring organisations to weigh a smoother sign in experience against reduced ability to hard-code browser-like behaviour.
- A mobile banking app opens the identity provider in a Custom Tab so the user can reuse an existing browser session and complete MFA without re-entering credentials.
- An enterprise app uses Custom Tabs for SSO so a workforce member who already authenticated in Chrome can continue without another password prompt, improving completion rates.
- A passkey-enabled consumer app relies on the system browser to surface platform authenticators, which is more reliable than trying to reproduce that flow inside a WebView.
- A device enrollment flow launches a browser-backed consent page, then returns an authorization code to the app through a redirect URI after the user grants access.
- For identity architecture context, NHI teams reviewing app-to-browser trust boundaries often pair this pattern with the operational lessons in Ultimate Guide to NHIs and browser-based OAuth guidance from the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Custom Tab is relevant to NHI security because many app-driven identity journeys are actually control points for tokens, delegated access, and approval events that later govern service accounts, API keys, or agent permissions. When a mobile app uses an embedded WebView instead of a browser-backed surface, the authentication flow can lose shared session state and weaken phishing resistance, which complicates secure handoff into downstream NHI workflows. NHIMG data shows that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, underscoring how often identity mistakes become operational incidents rather than theoretical weaknesses, as described in Ultimate Guide to NHIs. This is especially important when an app is used to approve access, register a device, or trigger a token issuance path that indirectly affects non-human identities. Browser-backed auth also supports the least-surprising user experience needed for strong identity assurance, which is consistent with NIST Cybersecurity Framework 2.0 principles around protecting identities and access pathways. Organisations typically encounter the risks only after a compromised or brittle app login breaks token issuance or session continuity, at which point Custom Tab becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Custom Tab supports controlled identity flows that depend on verified user access. |
| NIST SP 800-63 | Browser-mediated auth supports modern authenticators and federation patterns covered by digital identity guidance. | |
| NIST Zero Trust (SP 800-207) | Zero Trust assumes continuous trust evaluation across the app-to-identity boundary. | |
| OWASP Agentic AI Top 10 | Agentic and app-driven auth flows must avoid brittle embedded login surfaces. | |
| OWASP Non-Human Identity Top 10 | NHI-02 | Identity flows that mint or approve non-human access should avoid weak embedded surfaces. |
Prefer system-browser authentication when passkeys, federation, or strong authenticator binding are required.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
