Mobile app authentication for native iOS and Android apps
Mobile app authentication should open the system browser for sign-in, use the authorization code flow with PKCE from OAuth 2.1, and keep the user signed in with an offline refresh token that rotates on every use. The Skycloak Platform is built to run that sign-in for your native apps, so your app never handles a password itself.
Why native apps sign in through the system browser
A native app that shows its own username and password fields, or loads the sign-in page in an embedded web view, can read the user's password and teaches users to type it into any screen that asks for it. The recommended pattern for native apps is to open the sign-in page in the system browser, or in the in-app browser tab the operating system provides, which your app cannot read into. The user signs in there, and the browser hands an authorization code back to your app through a redirect. Because the browser already holds the user's session and saved credentials, signing in again is often quicker than typing into a form.
A mobile app cannot keep a client secret, since anyone can unpack the app and read it, so OAuth 2.1 requires PKCE (proof key for code exchange) for this flow. The app creates a random secret for each sign-in, sends a hash of it with the request and sends the secret itself when it exchanges the code for tokens. Another app that intercepts the redirect gets a code it cannot use, because it never had the secret. The Platform speaks OpenID Connect and OAuth 2.1, so any standard client library that follows this pattern can sign your users in.
How offline refresh tokens keep users signed in
People expect a mobile app to remember them for days, while access tokens should last only minutes, so the app needs a refresh token to get new access tokens in the background. The Platform is built so that an app that requests the offline_access scope gets an offline refresh token, which is separate from the browser's single sign-on session and does not end when that session does. The planned lifetime is 7 days by default, which you will be able to extend up to 30 days for each app. That will let you choose a shorter lifetime for an app that handles sensitive data and a longer one for an app where signing in again would only get in the way.
The offline refresh token is designed to rotate on each use, which means every refresh returns a new token and retires the old one. If an old token is ever presented again, reuse detection is meant to treat that as a sign the token was copied, so a stolen copy stops being useful. The token is also planned to be revoked when the user logs out of that app, when your backend calls the revoke endpoint or when an administrator revokes it, and logging out of one app is meant to end that app's token only, so the user stays signed in to your other apps.
Passkeys and multi-factor authentication on phones
A passkey is a sign-in credential stored on the user's device and unlocked with a fingerprint, a face scan or the device PIN, so there is no password to type or to phish. Phones suit passkeys well, because the key sits on the device the user is already holding and the operating system can sync it to the user's other devices. Since your app signs in through the system browser, the passkey prompt comes from the operating system, and your app needs no passkey code of its own.
Passkeys and multi-factor authentication are on the Platform's plan, along with a breached password check for users who still sign in with a password. Each environment of your app, such as production and staging, is its own tenant with its own users and sign-in address, so test accounts never mix with real ones. We list a feature as available only after it ships, and a demo is where you can see which of these your mobile app can use today.
Frequently asked questions
Should a mobile app use an embedded web view for sign-in?
No. An embedded web view lets the app read what the user types, and it does not share the browser's saved session or passkeys. Use the system browser or the operating system's in-app browser tab, with the authorization code flow and PKCE.
How long does a user stay signed in to a mobile app?
On the Platform, for as long as the app's offline refresh token is valid, with a planned default of 7 days and up to 30 days if you set that for the app. Logging out of the app, a revoke call or an administrator is meant to end it sooner.
See the Skycloak Platform for yourself
Book a demo and we will walk you through the Platform with your own sign-in flows in mind.