Native mobile integration
Secure a Mobile Application
Choose the Apple iOS or Google Android implementation path. Both use user-bound authorization, short-lived tokens, hardware-backed keys where available, device proof, server-side policy, and explicit revocation.
Production endpoints, credentials, native attestation, cloud integrations, and release certification remain environment-specific.
Choose a native platform
Foundation
Start HereRegister package or bundle identities, owners, environments, redirects, and callbacks.Open →Test ModeUse isolated users, devices, policies, and failure simulations.Open →Quick StartValidate the protected server call before integrating the client.Open →Developer ToolsDownload shared Postman, .NET, command-line, and webhook assets.Open →
Implementation steps
Create separate application identities for iOS and Android.
Never embed a tenant-wide signing secret in a mobile package.
Bind authorization to exact redirects and application identifiers.
Verify device and integrity signals on the server.
Test reinstall, device reset, token theft, offline behavior, and revocation.
Use a backend-for-frontend trust boundary
Native app→OAuth + PKCE→B5-aware backend→Protected APIs
Native client holds
Short-lived user authority, a device-held key, secure-storage refresh material, and attestation evidence.
Backend holds
Tenant or workload credentials, policy authority, entitlement checks, evidence, and final API authorization.
Release boundary: Production endpoints, credentials, native attestation, cloud integrations, and release certification remain environment-specific.
Developer Relations
Talk to a human.
Get architecture guidance, Test Mode access, integration review, or help choosing the right B5 identity and authorization pattern.