Everything in the app can be read and changed by its user, so the server must make every authorization decision. The app's job is to use the protocols correctly: the system browser and PKCE for OAuth, and tokens kept out of reach of other apps.
- Enforce authentication and authorization on the server for every request; never trust a client-side flag or hidden button.
- Sign in through the system browser with PKCE, as RFC 8252 describes for native apps, not an embedded WebView.
- Keep tokens short-lived, store refresh tokens in the platform keystore and revoke them on sign-out.
MASTG tests in the local projects
Neither local project runs a MASTG test for MASVS-AUTH-1. The guides below explain the platform mechanisms, and the control’s page on mas.owasp.org links the MASTG tests and weaknesses OWASP maps to it.
Guides on this site
Review trust boundaries in mobile and native clients
Protect local data and platform interactions while keeping server-side authorization independent of the client’s behavior.
OAuth 2.0 and OpenID Connect login: authorization code with PKCE
Implement OAuth 2.0 and OpenID Connect login with the authorization code flow and PKCE, keep each transaction bound to its browser, and block redirect, mix-up, code-injection and token-theft attacks.
Worked threat model: a mobile banking app
A complete worked threat model for a mobile banking-style app: the data-flow diagram and its elements, STRIDE threats on the client, the transport and the backend, and the mitigations mapped to OWASP MASVS v2 controls and current Android and iOS platform APIs.
Practice
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
Control statements are quoted from OWASP MASVS v2.1.0, licensed CC BY-SA 4.0; the rest is this site's summary. MASTG tests are those the iOS and Android projects here run, with their titles from mas.owasp.org. License.