Securing OAuth Tokens in Web and Mobile Applications Quiz

Enhance your understanding of OAuth token security in web and mobile apps with this quiz assessing best practices, attack prevention, and secure storage. Learn crucial concepts in protecting OAuth tokens during development and security testing.

  1. Token Storage Location

    In a mobile application handling OAuth tokens, which is the safest built-in storage option to prevent unauthorized access to the token?

    1. Secure device keychain or secure storage area
    2. Plaintext within app source files
    3. Public external storage on the device
    4. Session cookies with no encryption

    Explanation: Storing tokens in the device keychain or a dedicated secure storage area is recommended, as these locations are designed for sensitive data protection and limit access to authorized processes. Storing tokens in plaintext exposes them to reverse engineering, public external storage can be accessed by other apps, and session cookies without encryption may be intercepted. Each distractor lacks adequate built-in security controls for storing sensitive tokens.

  2. Token Transmission

    Why is it essential to use TLS (HTTPS) when transmitting OAuth tokens between a client app and a server?

    1. TLS encrypts traffic and protects tokens from interception
    2. TLS increases network speed for token transmission
    3. TLS ensures token length remains consistent
    4. TLS prevents token expiration on the server

    Explanation: TLS (HTTPS) encrypts network traffic, ensuring OAuth tokens are not transmitted in cleartext and are protected against interception or eavesdropping. While TLS may slightly impact speed, its main function is security, not performance. Token length and expiry are managed by the token issuer, not by the use of TLS. The other options conflate TLS with unrelated behaviors.

  3. Refresh Token Security

    In OAuth implementations, why should long-lived refresh tokens be handled with extra caution compared to short-lived access tokens?

    1. Refresh tokens can grant new access tokens if stolen
    2. Refresh tokens are generally shorter than access tokens
    3. Refresh tokens never expire under any conditions
    4. Refresh tokens are required in every API request

    Explanation: Refresh tokens, if compromised, allow attackers to obtain new access tokens and potentially gain prolonged unauthorized access. These tokens often last far longer than access tokens, increasing their appeal to attackers. Refresh tokens are not always shorter, and, depending on policy, they may expire. They also are not sent with every API request, unlike access tokens.

  4. Preventing Token Leakage in Web Apps

    Which strategy best prevents OAuth tokens from being exposed through URLs in a single-page web application?

    1. Use the authorization code flow with PKCE
    2. Embed tokens in the browser's local storage
    3. Include access tokens in URL fragments
    4. Disable all redirect URIs for the app

    Explanation: The authorization code flow with PKCE keeps tokens out of URLs by exchanging a code for tokens securely. Embedding tokens in local storage exposes them to XSS risks, while using URL fragments may result in token leakage via browser history or logs. Disabling all redirect URIs would prevent authorization altogether. The correct flow balances usability and security.

  5. Common Attack: Token Replay

    If an attacker intercepts an OAuth access token during an insecure network transmission, which type of attack is most likely to occur if protective measures are not implemented?

    1. Replay attack using the stolen token
    2. Brute-forcing the user's password
    3. Token signing using private keys
    4. SQL injection against the token endpoint

    Explanation: If an attacker captures an access token, they may perform a replay attack by sending the token to the resource server for unauthorized access. Brute-forcing passwords is unrelated to token interception. Signing tokens with private keys applies to token issuers, not attackers. SQL injection targets a different layer entirely. Thus, replaying the token is the most direct consequence.