You open a banking app on Friday, and your balance is already on the screen. You did not type a password, and the app did not ask for one. That convenience depends on a small set of credentials stored on the phone, and how they are built decides how much damage a stolen phone or a malicious app can do.

What the app holds, and what it should never hold

The app should not keep your password. A password is a long-lived secret, and a copy on the phone would be exposed by any compromise of the device or its backups.

Instead, the app exchanges your sign-in for tokens issued by the identity service. Two kinds matter most.

Credential	How long it lasts	What it lets the app do
Access token	Short, often minutes	Call the bank’s servers for a specific request
Refresh token	Longer	Ask for a new access token when the old one expires

For example, when the access token expires while you are reading your statement, the app uses the refresh token in the background. You see nothing, and no password is involved. The longer-lived credential is the valuable one, so it needs the most protection.

Why the sign-in should happen in the system browser

When you tap sign in, a well-built app opens the system browser or a secure browser sheet, not a login form inside its own screen. The IETF’s best current practice for native apps says authorization requests should be made through an external user-agent, typically the browser, rather than an embedded one (RFC 8252). For example, a banking app that opens a browser sheet for sign-in gives you the same login page your browser would show, so the app never sees the password.

The reason is trust. The RFC notes that an embedded login lets the host app copy user credentials and cookies, and makes the user authenticate from scratch in each app. A browser sheet controlled by the identity service and the operating system means the app only receives the result.

Why a stolen authorization code is not enough

During sign-in, the browser sends the app back with an authorization code. On a phone, another installed app can try to register the same redirect address and receive that code.

PKCE, the mechanism in RFC 7636, closes this gap. Before sign-in starts, the app creates a random secret and sends only a derived version of it to the server. The app must later prove it holds the original secret to exchange the code for tokens. A rogue app that catches the code cannot complete the exchange (OWASP OAuth 2.0 Cheat Sheet).

For example, a malicious game installed alongside your banking app registers the same redirect address. It catches the code, but the token exchange fails because it does not hold the secret the banking app created.

Refresh token rotation catches a copied token

A refresh token that can keep issuing access tokens for weeks is the most valuable item on the phone. For public clients such as mobile apps, RFC 9700 says refresh tokens must be either sender-constrained or rotated (RFC 9700 summary, WorkOS).

Rotation means each refresh issues a new refresh token and invalidates the old one. For example, if an attacker copies a refresh token and uses it, the legitimate app later tries to use the same, now-invalidated token. The server sees a reuse and can revoke the whole family of tokens, which forces a fresh sign-in.

Biometric sign-in releases a key, it does not replace the server check

Biometric sign-in feels like a login, but in a well-built app it opens a key on the phone. The key decrypts the stored refresh token. The server still receives a token, not a fingerprint.

On Android, the Keystore can hold a key that requires user authentication. OWASP’s Android testing guide describes keys created with user-authentication requirements and invalidation on biometric enrollment, which can be used through BiometricPrompt’s crypto object, so the key cannot be used until the biometric check succeeds (OWASP MASTG, Local Authentication).

Invalidation on enrollment has a visible effect. When a new fingerprint is added, the key is invalidated, and the app asks for a sign-in again. For example, a family member who adds their own fingerprint to your phone should not inherit an open banking session. In general practice, iOS uses the Keychain with access controls tied to biometrics for the same purpose; confirm the exact configuration against Apple’s current documentation before relying on it.

Where sessions should end

Logging out should revoke the refresh token on the server, not only clear the screen and the app’s storage. If the app only clears local storage, a copy of the refresh token can keep working until it expires.

For example, you lose your phone on a train. From a laptop, you open the bank’s website and end the sessions on the lost device. Once the server revokes those tokens, a copy taken from the phone stops working, even though the thief still holds the device.

Idle lock and step-up are separate controls. For example, a banking app locks after a few minutes in the background, but changing a payee still asks for a fresh factor even when the app is already open. An idle lock asks whether the phone has been left unattended. Step-up asks for a fresh factor before a sensitive action.

Our post on types of MFA used in online banking compares the factors a step-up can use.

What OmniDefend’s customer identity offering covers

OmniDefend’s customer identity offering describes multi-factor identification for customer transactions, online or on-premise. It lists transaction verification and user management APIs among its capabilities, which are the parts an app’s identity layer relies on. For example, a bank’s app can call transaction verification before a transfer goes through, while the identity records stay in one place.

OmniDefend’s product listing does not describe a mobile software development kit, token storage on the device, or biometric key handling inside an app. Those stay with the app team and the platform’s own security features. For how password-less sign-in on the web works, see our post on passwordless authentication and how it works.

Test a sign-in on a real phone

The most useful test uses a real phone, a real account, and a real logout. Check each step against what should happen.

Sign-in: Does the sign-in open in a system browser sheet rather than an in-app form?
Token life: Does the access token expire on schedule, and does the refresh token rotate on use?
New fingerprint: After a new fingerprint is added, is a fresh sign-in required?
Logout: After logout on the phone, does the old refresh token stop working on the server?
Lost device: Can you end the sessions on that phone from another device?

OmniDefend’s sales team sets up the 30-day free trial, so the test runs on your own app and account setup rather than a sandbox. Start the free trial, or request a demo to see the customer identity capabilities first.

Frequently asked questions

Does the app see my password?

It should not. Sign-in should happen in a browser sheet controlled by the identity service, and the app should receive only the resulting tokens.

Why does the app ask me to sign in again after I add a fingerprint?

Adding a new biometric invalidates keys that were bound to the old set. The app treats the old session key as no longer trustworthy and asks for a fresh sign-in.

Is it safe to stay signed in on my phone?

It can be, when tokens are short-lived, stored in the phone’s secure storage, rotated, and protected by a screen lock or biometric. The risk rises when tokens never expire or when the phone is shared.

What happens if I lose my phone?

You should be able to end the session from another device or through the provider’s website. Once the server revokes the tokens, copies stop working.

Why might logging out take a moment?

A proper logout contacts the identity service to revoke the session, then clears local tokens. Skipping the revocation would leave the session valid on the server.

Resources

Ayush Bhansali

Ayush Bhansali is a seasoned writer with a passion for unraveling the intricacies of cyber security, workforce protection, and the cutting-edge realm of SAML 2.0, FIDO, OpenID Connect and FIDO 2.0. With three years of dedicated experience, Ayush has honed his expertise in dissecting the ever-evolving landscape of technology and its impact on our digital lives. His insightful articles not only demystify complex concepts but also provide practical insights for individuals and organizations looking to fortify their digital defenses. Ayush’s writing style is characterized by its clarity and accessibility, making even the most intricate topics comprehensible to a wide audience. Through his work, Ayush strives to empower readers with the knowledge they need to navigate the rapidly advancing world of technology securely.