A team proposes the OAuth password grant for your first-party mobile app because "it is our own app". Respond.

What the interviewer is testing

Whether you know the deprecated grant types and can explain why first-party status does not change the answer.

Why the password grant is wrong

It requires the application to handle the user's password directly, and that creates problems that have nothing to do with trust:

It cannot support multi-factor authentication, federated identity, passkeys, step-up authentication, or a CAPTCHA challenge — because the flow has no place for an interactive authorisation server interaction. That alone disqualifies it for most current requirements.

It trains users to enter credentials in application-rendered forms, which is the behaviour phishing depends on.

It puts the password in the app's memory and potentially its logs, expanding the attack surface with no benefit.

It is deprecated in current OAuth guidance for these reasons, and the deprecation is not about whether the client is trusted.

The correct flow

Authorisation code with PKCE, using the system browser or an in-app browser tab rather than an embedded web view.

The system browser matters: it has the user's existing session (so single sign-on works), it shows the real address bar (so the user can verify the domain), and the application never sees the credentials.

PKCE binds the authorisation code to the requesting client, which prevents interception on the redirect — the specific attack that made the plain authorisation code flow unsafe on mobile.

The user experience objection, addressed

Teams resist because the browser handoff feels less polished. In practice, in-app browser tabs are visually integrated, and the flow enables biometric unlock, passkeys and single sign-on across the organisation's apps — which is a better experience than a password form, not a worse one.

What a strong answer adds

Refresh token handling on mobile: use rotation with reuse detection, store tokens in the platform's secure storage rather than in application preferences, and bind them to the device where the platform supports it.

Common weak answers

Accepting it because the app is first-party. Rejecting it without explaining what capabilities are lost.