Skip to content

Mobile App Authentication Architectures

Authentication and authorization problems are prevalent security vulnerabilities. In fact, they consistently rank second highest in the OWASP Top 10.

Most mobile apps implement some kind of user authentication. Even though part of the authentication and state management logic is performed by the backend service, authentication is such an integral part of most mobile app architectures that understanding its common implementations is important.

Since the basic concepts are identical on iOS and Android, we’ll discuss prevalent authentication and authorization architectures and pitfalls in this generic guide. OS-specific authentication issues, such as local and biometric authentication, will be discussed in the respective OS-specific chapters.

General Assumptions

Appropriate Authentication is in Place

Perform the following steps when testing authentication and authorization:

  • Identify the additional authentication factors the app uses.
  • Locate all endpoints that provide critical functionality.
  • Verify that the additional factors are strictly enforced on all server-side endpoints.

Authentication bypass vulnerabilities exist when authentication state is not consistently enforced on the server and when the client can tamper with the state. While the backend service is processing requests from the mobile client, it must consistently enforce authorization checks: verifying that the user is logged in and authorized every time a resource is requested.

Consider the following example from the OWASP Web Testing Guide. In the example, a web resource is accessed through a URL, and the authentication state is passed through a GET parameter:

http://www.site.com/page.asp?authenticated=no

The client can arbitrarily change the GET parameters sent with the request. Nothing prevents the client from simply changing the value of the authenticated parameter to “yes”, effectively bypassing authentication.

Although this is a simplistic example that you probably won’t find in the wild, programmers sometimes rely on “hidden” client-side parameters, such as cookies, to maintain authentication state. They assume that these parameters can’t be tampered with. Consider, for example, the following classic vulnerability in Nortel Contact Center Manager. The administrative web application of Nortel’s appliance relied on the cookie “isAdmin” to determine whether the logged-in user should be granted administrative privileges. Consequently, it was possible to get admin access by simply setting the cookie value as follows:

isAdmin=True

Security experts used to recommend using session-based authentication and maintaining session data on the server only. This prevents any form of client-side tampering with the session state. However, the whole point of using stateless authentication instead of session-based authentication is to not have session state on the server. Instead, state is stored in client-side tokens and transmitted with every request. In this case, seeing client-side parameters such as isAdmin is perfectly normal.

To prevent tampering cryptographic signatures are added to client-side tokens. Of course, things may go wrong, and popular implementations of stateless authentication have been vulnerable to attacks. For example, the signature verification of some JSON Web Token (JWT) implementations could be deactivated by setting the signature type to “None”.

Best Practices for Passwords

Password strength is a key concern when passwords are used for authentication. The password policy defines requirements to which end users should adhere. A password policy typically specifies password length, password complexity, and password topologies. A “strong” password policy makes manual or automated password cracking difficult or impossible. For further information please consult the OWASP Authentication Cheat Sheet.

General Guidelines on Testing Authentication

There’s no one-size-fits-all approach to authentication. When reviewing the authentication architecture of an app, you should first consider whether the authentication method(s) used are appropriate in the given context. Authentication can be based on one or more of the following:

  • Something the user knows (password, PIN, pattern, etc.)
  • Something the user has (SIM card, one-time password generator, or hardware token)
  • A biometric property of the user (fingerprint, retina, voice)

The number of authentication procedures implemented by mobile apps depends on the sensitivity of the functions or accessed resources. Refer to industry best practices when reviewing authentication functions. Username/password authentication (combined with a reasonable password policy) is generally considered sufficient for apps that have a user login and aren’t very sensitive. This form of authentication is used by most social media apps.

For sensitive apps, adding a second authentication factor is usually appropriate. This includes apps that provide access to very sensitive information (such as credit card numbers) or allow users to transfer funds. In some industries, these apps must also comply with certain standards. For example, financial apps have to ensure compliance with the Payment Card Industry Data Security Standard (PCI DSS), the Gramm Leach Bliley Act, and the Sarbanes-Oxley Act (SOX). Compliance considerations for the US health care sector include the Health Insurance Portability and Accountability Act (HIPAA) and the Patient Safety Rule.

Stateful vs. Stateless Authentication

You’ll usually find that the mobile app uses HTTP as the transport layer. The HTTP protocol itself is stateless, so there must be a way to associate a user’s subsequent HTTP requests with that user. Otherwise, the user’s log in credentials would have to be sent with every request. Also, both the server and client need to keep track of user data (e.g., the user’s privileges or role). This can be done in two different ways:

  • With stateful authentication, a unique session id is generated when the user logs in. In subsequent requests, this session ID serves as a reference to the user details stored on the server. The session ID is opaque; it doesn’t contain any user data.

  • With stateless authentication, all user-identifying information is stored in a client-side token. The token can be passed to any server or micro service, eliminating the need to maintain session state on the server. Stateless authentication is often factored out to an authorization server, which produces, signs, and optionally encrypts the token upon user login.

Web applications commonly use stateful authentication with a random session ID that is stored in a client-side cookie. Although mobile apps sometimes use stateful sessions in a similar fashion, stateless token-based approaches are becoming popular for a variety of reasons:

  • They improve scalability and performance by eliminating the need to store session state on the server.
  • Tokens enable developers to decouple authentication from the app. Tokens can be generated by an authentication server, and the authentication scheme can be changed seamlessly.

As a mobile security tester, you should be familiar with both types of authentication.

Stateful Authentication

Stateful (or “session-based”) authentication is characterized by authentication records on both the client and server. The authentication flow is as follows:

  1. The app sends a request with the user’s credentials to the backend server.
  2. The server verifies the credentials. If the credentials are valid, the server creates a new session along with a random session ID.
  3. The server sends to the client a response that includes the session ID.
  4. The client sends the session ID with all subsequent requests. The server validates the session ID and retrieves the associated session record.
  5. After the user logs out, the server-side session record is destroyed and the client discards the session ID.

When sessions are improperly managed, they are vulnerable to a variety of attacks that may compromise the session of a legitimate user, allowing the attacker to impersonate the user. This may result in lost data, compromised confidentiality, and illegitimate actions.

Best Practices:

Locate any server-side endpoints that provide sensitive information or functions and verify the consistent enforcement of authorization. The backend service must verify the user’s session ID or token and make sure that the user has sufficient privileges to access the resource. If the session ID or token is missing or invalid, the request must be rejected.

Make sure that:

  • Session IDs are randomly generated on the server side.
  • The IDs can’t be guessed easily (use proper length and entropy).
  • Session IDs are always exchanged over secure connections (e.g. HTTPS).
  • The mobile app doesn’t save session IDs in permanent storage.
  • The server verifies the session whenever a user tries to access privileged application elements (a session ID must be valid and must correspond to the proper authorization level).
  • The session is terminated on the server side and session information deleted within the mobile app after it times out or the user logs out.

Authentication shouldn’t be implemented from scratch but built on top of proven frameworks. Many popular frameworks provide ready-made authentication and session management functionality. If the app uses framework APIs for authentication, check the framework security documentation for best practices. Security guides for common frameworks are available at the following links:

A great resource for testing server-side authentication is the OWASP Web Testing Guide, specifically the Testing Authentication and Testing Session Management chapters.

Stateless Authentication

Token-based authentication is implemented by sending a signed token (verified by the server) with each HTTP request. The most commonly used token format is the JSON Web Token, defined in RFC7519. A JWT may encode the complete session state as a JSON object. Therefore, the server doesn’t have to store any session data or authentication information.

JWT tokens consist of three Base64Url-encoded parts separated by dots. The Token structure is as follows:

base64UrlEncode(header).base64UrlEncode(payload).base64UrlEncode(signature)

The following example shows a Base64Url-encoded JSON Web Token:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Ikpva
G4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

The header typically consists of two parts: the token type, which is JWT, and the hashing algorithm being used to compute the signature. In the example above, the header decodes as follows:

{"alg":"HS256","typ":"JWT"}

The second part of the token is the payload, which contains so-called claims. Claims are statements about an entity (typically, the user) and additional metadata. For example:

{"sub":"1234567890","name":"John Doe","admin":true}

The signature is created by applying the algorithm specified in the JWT header to the encoded header, encoded payload, and a secret value. For example, when using the HMAC SHA256 algorithm the signature is created in the following way:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Note that the secret is shared between the authentication server and the backend service - the client does not know it. This proves that the token was obtained from a legitimate authentication service. It also prevents the client from tampering with the claims contained in the token.

Best Practices:

Verify that the implementation adheres to JWT best practices:

  • Verify that the HMAC is checked for all incoming requests containing a token.
  • Verify that the private signing key or HMAC secret key is never shared with the client. It should be available for the issuer and verifier only.
  • Verify that no sensitive data, such as personal identifiable information, is embedded in the JWT. For example, by decoding the base64-encoded JWT and find out what kind of data it transmits and whether that data is encrypted. If, for some reason, the architecture requires transmission of such information in the token, make sure that payload encryption is being applied. See the sample Java implementation on the OWASP JWT Cheat Sheet.
  • Make sure that replay attacks are addressed with the jti (JWT ID) claim, which gives the JWT a unique identifier.
  • Make sure that cross service relay attacks are addressed with the aud (audience) claim, which defines for which application the token is entitled.
  • Verify that tokens are stored securely on the mobile phone, with, for example, KeyChain (iOS) or KeyStore (Android).
  • Verify that the hashing algorithm is enforced. A common attack includes altering the token to use an empty signature (e.g., signature = “”) and set the signing algorithm to none, indicating that “the integrity of the token has already been verified”. Some libraries might treat tokens signed with the none algorithm as if they were valid tokens with verified signatures, so the application will trust altered token claims.
  • Verify that tokens include an “exp” expiration claim and the backend doesn’t process expired tokens. A common method of granting tokens combines access tokens and refresh tokens. When the user logs in, the backend service issues a short-lived access token and a long-lived refresh token. The application can then use the refresh token to obtain a new access token, if the access token expires.

There are two different Burp Plugins that can help you for testing the vulnerabilities listed above:

Also, make sure to check out the OWASP JWT Cheat Sheet for additional information.

OAuth 2.0

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to user accounts on remote HTTP services such as APIs and web-enabled applications.

Common uses for OAuth2 include:

  • Getting permission from the user to access an online service using their account.
  • Authenticating to an online service on behalf of the user.
  • Handling authentication errors.

According to OAuth 2.0, a mobile client seeking access to a user’s resources must first ask the user to authenticate against an authentication server. With the users’ approval, the authorization server then issues a token that allows the app to act on behalf of the user. Note that the OAuth2 specification doesn’t define any particular kind of authentication or access token format.

Protocol Overview

OAuth 2.0 defines four roles:

  • Resource Owner: the account owner
  • Client: the application that wants to access the user’s account with the access tokens
  • Resource Server: hosts the user accounts
  • Authorization Server: verifies user identity and issues access tokens to the application

Note: The API fulfills both the Resource Owner and Authorization Server roles. Therefore, we will refer to both as the API.

Here is a more detailed explanation of the steps in the diagram:

  1. The application requests user authorization to access service resources.
  2. If the user authorizes the request, the application receives an authorization grant. The authorization grant may take several forms (explicit, implicit, etc.).
  3. The application requests an access token from the authorization server (API) by presenting authentication of its own identity along with the authorization grant.
  4. If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application, completing the authorization process. The access token may have a companion refresh token.
  5. The application requests the resource from the resource server (API) and presents the access token for authentication. The access token may be used in several ways (e.g., as a bearer token).
  6. If the access token is valid, the resource server (API) serves the resource to the application.

In OAuth2, the user agent is the entity that performs the authentication. OAuth2 authentication can be performed either through an external user agent (e.g. Chrome or Safari) or in the app itself (e.g. through a WebView embedded into the app or an authentication library). None of the two modes is intrinsically “better” than the other. The choice depends on the app’s specific use case and threat model.

External User Agent: Using an external user agent is the method of choice for apps that need to interact with social media accounts (Facebook, Twitter, etc.). Advantages of this method include:

  • The user’s credentials are never directly exposed to the app. This guarantees that the app cannot obtain the credentials during the login process (“credential phishing”).
  • Almost no authentication logic must be added to the app itself, preventing coding errors.

On the negative side, there is no way to control the behavior of the browser (e.g. to activate certificate pinning).

Embedded User Agent: Using an embedded user agent is the method of choice for apps that need to operate within a closed ecosystem, for example to interact with corporate accounts. For example, consider a banking app that uses OAuth2 to retrieve an access token from the bank’s authentication server, which is then used to access a number of micro services. In that case, credential phishing is not a viable scenario. It is likely preferable to keep the authentication process in the (hopefully) carefully secured banking app, instead of placing trust on external components.

Best Practices

For additional best practices and detailed information please refer to the following source documents:

Some of the best practices include but are not limited to:

  • User agent:
    • The user should have a way to visually verify trust (e.g., Transport Layer Security (TLS) confirmation, website mechanisms).
    • To prevent man-in-the-middle attacks, the client should validate the server’s fully qualified domain name with the public key the server presented when the connection was established.
  • Type of grant:
    • On native apps, code grant should be used instead of implicit grant.
    • When using code grant, PKCE (Proof Key for Code Exchange) should be implemented to protect the code grant. Make sure that the server also implements it.
    • The auth “code” should be short-lived and used immediately after it is received. Verify that auth codes only reside on transient memory and aren’t stored or logged.
  • Client secrets:
    • Shared secrets should not be used to prove the client’s identity because the client could be impersonated (“client_id” already serves as proof). If they do use client secrets, be sure that they are stored in secure local storage.
  • End-User credentials:
    • Secure the transmission of end-user credentials with a transport-layer method, such as TLS.
  • Tokens:
    • Keep access tokens in transient memory.
    • Access tokens must be transmitted over an encrypted connection.
    • Reduce the scope and duration of access tokens when end-to-end confidentiality can’t be guaranteed or the token provides access to sensitive information or transactions.
    • Remember that an attacker who has stolen tokens can access their scope and all resources associated with them if the app uses access tokens as bearer tokens with no other way to identify the client.
    • Store refresh tokens in secure local storage; they are long-term credentials.

User Logout

Failing to destroy the server-side session is one of the most common logout functionality implementation errors. This error keeps the session or token alive, even after the user logs out of the application. An attacker who gets valid authentication information can continue to use it and hijack a user’s account.

Many mobile apps don’t automatically log users out. There can be various reasons, such as: because it is inconvenient for customers, or because of decisions made when implementing stateless authentication. The application should still have a logout function, and it should be implemented according to best practices, destroying all locally stored tokens or session identifiers.

If session information is stored on the server, it should be destroyed by sending a logout request to that server. In case of a high-risk application, tokens should be invalidated. Not removing tokens or session identifiers can result in unauthorized access to the application in case the tokens are leaked. Note that other sensitive types of information should be removed as well, as any information that is not properly cleared may be leaked later, for example during a device backup.

Here are different examples of session termination for proper server-side logout:

If access and refresh tokens are used with stateless authentication, they should be deleted from the mobile device. The refresh token should be invalidated on the server.

The OWASP Web Testing Guide (WSTG-SESS-06) includes a detailed explanation and more test cases.

Supplementary Authentication

Authentication schemes are sometimes supplemented by passive contextual authentication, which can incorporate:

  • Geolocation
  • IP address
  • Time of day
  • The device being used

Ideally, in such a system the user’s context is compared to previously recorded data to identify anomalies that might indicate account abuse or potential fraud. This process is transparent to the user, but can become a powerful deterrent to attackers.

Two-factor Authentication

Two-factor authentication (2FA) is standard for apps that allow users to access sensitive functions and data. Common implementations use a password for the first factor and any of the following as the second factor:

  • One-time password via SMS (SMS-OTP)
  • One-time code via phone call
  • Hardware or software token
  • Push notifications in combination with PKI and local authentication

Whatever option is used, it always must be enforced and verified on the server-side and never on client-side. Otherwise the 2FA can be easily bypassed within the app.

The 2FA can be performed at login or later in the user’s session.

For example, after logging in to a banking app with a username and PIN, the user is authorized to perform non-sensitive tasks. Once the user attempts to execute a bank transfer, the second factor (“step-up authentication”) must be presented.

Best Practices:

  • Don’t roll your own 2FA: There are various two-factor authentication mechanisms available which can range from third-party libraries, usage of external apps to self implemented checks by the developers.
  • Use short-lived OTPs: A OTP should be valid for only a certain amount of time (usually 30 seconds) and after keying in the OTP wrongly several times (usually 3 times) the provided OTP should be invalidated and the user should be redirected to the landing page or logged out.
  • Store tokens securely: To prevent these kind of attacks, the application should always verify some kind of user token or other dynamic information related to the user that was previously securely stored (e.g. in the Keychain/KeyStore).

SMS-OTP

Although one-time passwords (OTP) sent via SMS are a common second factor for two-factor authentication, this method has its shortcomings. In 2016, NIST suggested: “Due to the risk that SMS messages may be intercepted or redirected, implementers of new systems SHOULD carefully consider alternative authenticators.”. Below you will find a list of some related threats and suggestions to avoid successful attacks on SMS-OTP.

Threats:

  • Wireless Interception: The adversary can intercept SMS messages by abusing femtocells and other known vulnerabilities in the telecommunications network.
  • Trojans: Installed malicious applications with access to text messages may forward the OTP to another number or backend.
  • SIM SWAP Attack: In this attack, the adversary calls the phone company, or works for them, and has the victim’s number moved to a SIM card owned by the adversary. If successful, the adversary can see the SMS messages which are sent to the victim’s phone number. This includes the messages used in the two-factor authentication.
  • Verification Code Forwarding Attack: This social engineering attack relies on the trust the users have in the company providing the OTP. In this attack, the user receives a code and is later asked to relay that code using the same means in which it received the information.
  • Voicemail: Some two-factor authentication schemes allow the OTP to be sent through a phone call when SMS is no longer preferred or available. Many of these calls, if not answered, send the information to voicemail. If an attacker was able to gain access to the voicemail, they could also use the OTP to gain access to a user’s account.

You can find below several suggestions to reduce the likelihood of exploitation when using SMS for OTP:

  • Messaging: When sending an OTP via SMS, be sure to include a message that lets the user know 1) what to do if they did not request the code 2) your company will never call or text them requesting that they relay their password or code.
  • Dedicated Channel: When using the OS push notification feature (APN on iOS and FCM on Android), OTPs can be sent securely to a registered application. This information is, compared to SMS, not accessible by other applications. Alternatively of a OTP the push notification could trigger a pop-up to approve the requested access.
  • Entropy: Use authenticators with high entropy to make OTPs harder to crack or guess and use at least 6 digits. Make sure that digits are separates in smaller groups in case people have to remember them to copy them to your app.
  • Avoid Voicemail: If a user prefers to receive a phone call, do not leave the OTP information as a voicemail.

SMS-OTP Research:

  • [#dmitrienko] Dmitrienko, Alexandra, et al. “On the (in) security of mobile two-factor authentication.” International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2014.
  • [#grassi] Grassi, Paul A., et al. Digital identity guidelines: Authentication and lifecycle management (DRAFT). No. Special Publication (NIST SP)-800-63B. 2016.
  • [#grassi2] Grassi, Paul A., et al. Digital identity guidelines: Authentication and lifecycle management. No. Special Publication (NIST SP)-800-63B. 2017.
  • [#konoth] Konoth, Radhesh Krishnan, Victor van der Veen, and Herbert Bos. “How anywhere computing just killed your phone-based two-factor authentication.” International Conference on Financial Cryptography and Data Security. Springer, Berlin, Heidelberg, 2016.
  • [#mulliner] Mulliner, Collin, et al. “SMS-based one-time passwords: attacks and defense.” International Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, Berlin, Heidelberg, 2013.
  • [#siadati] Siadati, Hossein, et al. “Mind your SMSes: Mitigating social engineering in second factor authentication.” Computers & Security 65 (2017): 14-28.
  • [#siadati2] Siadati, Hossein, Toan Nguyen, and Nasir Memon. “Verification code forwarding attack (short paper).” International Conference on Passwords. Springer, Cham, 2015.

Transaction Signing with Push Notifications and PKI

Another alternative and strong mechanisms to implement a second factor is transaction signing.

Transaction signing requires authentication of the user’s approval of critical transactions. Asymmetric cryptography is the best way to implement transaction signing. The app will generate a public/private key pair when the user signs up, then registers the public key on the backend. The private key is securely stored in the KeyStore (Android) or KeyChain (iOS). To authorize a transaction, the backend sends the mobile app a push notification containing the transaction data. The user is then asked to confirm or deny the transaction. After confirmation, the user is prompted to unlock the Keychain (by entering the PIN or fingerprint), and the data is signed with user’s private key. The signed transaction is then sent to the server, which verifies the signature with the user’s public key.

Login Activity and Device Blocking

It is a best practice that apps should inform the user about all login activities within the app with the possibility of blocking certain devices. This can be broken down into various scenarios:

  1. The application provides a push notification the moment their account is used on another device to notify the user of different activities. The user can then block this device after opening the app via the push-notification.
  2. The application provides an overview of the last session after login. If the previous session was with a different configuration (e.g. location, device, app-version) compared to the current configuration, then the user should have the option to report suspicious activities and block devices used in the previous session.
  3. The application provides an overview of the last session after login at all times.
  4. The application has a self-service portal in which the user can see an audit-log. This allows the user to manage the different devices that are logged in.

The developer can make use of specific meta-information and associate it to each different activity or event within the application. This will make it easier for the user to spot suspicious behavior and block the corresponding device. The meta-information may include:

  • Device: The user can clearly identify all devices where the app is being used.
  • Date and Time: The user can clearly see the latest date and time when the app was used.
  • Location: The user can clearly identify the latest locations where the app was used.

The application can provide a list of activities history which will be updated after each sensitive activity within the application. The choice of which activities to audit needs to be done for each application based on the data it handles and the level of security risk the team is willing to have. Below is a list of common sensitive activities that are usually audited:

  • Login attempts
  • Password changes
  • Personal Identifiable Information changes (name, email address, telephone number, etc.)
  • Sensitive activities (purchase, accessing important resources, etc.)
  • Consent to Terms and Conditions clauses

Paid content requires special care, and additional meta-information (e.g., operation cost, credit, etc.) might be used to ensure user’s knowledge about the whole operation’s parameters.

In addition, non-repudiation mechanisms should be applied to sensitive transactions (e.g. paid content access, given consent to Terms and Conditions clauses, etc.) in order to prove that a specific transaction was in fact performed (integrity) and by whom (authentication).

Lastly, it should be possible for the user to log out specific open sessions and in some cases it might be interesting to fully block certain devices using a device identifier.