SecureStore cannot store strings longer than a JWT

It removes the distinction in exposure surface between the two tokens; reading or backing up that one entry exposes the refresh token even in code paths that only needed the access token

JSON.stringify is not available in the Hermes engine

SecureStore entries cannot be updated once written

A teammate suggests storing both the access token and refresh token together in a single `expo-secure-store` entry as a JSON string to simplify the code. What's the main concern with this approach?

A 15-question test to assess knowledge of secure token handling and storage practices in React Native applications, especially for healthcare apps.

In-memory storage is faster to read than disk storage

Disk-persisted tokens survive app kill, increasing exposure window if a short-lived token were ever leaked from storage

React Native does not support writing to disk on iOS

Memory storage automatically encrypts data using the device's secure hardware

What is the primary reason access tokens should be kept in memory rather than persisted to disk in a React Native app?

AsyncStorage has a smaller storage size limit than SecureStore

SecureStore is backed by iOS Keychain and Android Keystore, providing OS-level encrypted storage, while AsyncStorage stores data in plaintext

AsyncStorage only works on Android, not iOS

SecureStore is the only storage option that supports JSON objects

Why is `expo-secure-store` preferred over `AsyncStorage` for storing refresh tokens?

Short-lived tokens are cheaper to generate on the server

It travels on every API request and is therefore the credential most exposed to leakage (logs, proxies, crash reports), so its blast radius is minimized by limiting its useful lifetime

Mobile networks cannot reliably transmit tokens valid for longer than 15 minutes

OAuth specifications mandate this exact timeframe

In the access/refresh token pattern, why is the access token designed to be short-lived (e.g., 5-15 minutes)?

It reduces the size of the token payload sent over the network

It allows the app to skip biometric authentication on subsequent logins

It enables detection of token theft: if a previously-used (rotated-out) refresh token is replayed, the server can recognize this as a reuse-of-revoked-token event and revoke the entire token family

It automatically renews the user's OAuth client secret

What problem does "refresh token rotation" specifically address?

redux-persist cannot serialize nested objects

The default storage engine is AsyncStorage, which stores data unencrypted on the device

redux-persist only works with class components, not hooks

redux-persist requires a paid license for production apps

Why shouldn't sensitive clinical/PHI data be persisted via `redux-persist` using its default storage engine in a healthcare RN app?

It replaces the need for an access token entirely

It refreshes the access token without contacting the server

It addresses a scenario token validity alone cannot cover: confirming the same physical person is holding the device, even though the session is cryptographically still valid

It is required by Expo's SDK for all apps regardless of data sensitivity

What is the purpose of adding a biometric re-confirmation step (e.g., Face ID) on top of an already-valid OAuth session when the app returns from background?

Preventing the UI from showing multiple loading spinners at once

Avoiding parallel refresh-token calls that could trigger an IdP's reuse-detection (since rotated refresh tokens are typically single-use), which would otherwise incorrectly look like token theft

Ensuring requests are sent in alphabetical order

In the "single-flight" refresh pattern, what problem is being solved when multiple API calls receive a 401 simultaneously?

They make the token shorter, reducing bandwidth usage

They eliminate the need for an access token altogether

Even if the refresh token itself is copied/stolen, it's useless without the hardware-backed private key on the original device, so possession of the token string alone is insufficient

They allow the token to be shared safely across multiple devices

What is the main security benefit of sender-constrained tokens (e.g., via DPoP or mTLS client certificates) over a standard bearer refresh token?

It prevents man-in-the-middle interception of tokens in transit, which is a separate threat from at-rest storage compromise

It is required for HealthKit integration on iOS

Why is certificate pinning relevant to protecting tokens, even though tokens are already stored securely on-device?

The app's biometric prompt, which blocks all API calls regardless of token validity

Absolute and idle expiration policies, which ensure the token becomes unusable after a maximum lifetime or period of inactivity even if never explicitly revoked

The access token's short TTL, since refresh tokens inherit the same expiration

EAS Update, which can patch the token remotely

If a refresh token is stolen by an attacker but rotation/reuse-detection somehow fails to catch it, which mechanism still bounds the potential damage?

`react-native-webview` with a custom `postMessage` bridge to inject tokens

`expo-auth-session` (using `ASWebAuthenticationSession`/Chrome Custom Tabs under the hood) or `react-native-app-auth` for AppAuth-compliant flows

`fetch` with manual `Authorization: Basic` headers

`expo-secure-store` configured with an OAuth provider URL

Which library combination is most appropriate for implementing a PKCE-compliant OAuth/OIDC login flow in an Expo-managed React Native app, while avoiding an embedded login WebView?

AsyncStorage.setItem('refreshToken', token)

await SecureStore.setItemAsync('refreshToken', token, { keychainAccessible: SecureStore.WHEN_UNLOCKED })

localStorage.setItem('refreshToken', token)

You need to store a refresh token securely in an Expo-managed RN app. Which snippet correctly does this using `expo-secure-store`?

Inside each individual component's `useEffect`, checking response status manually

In a custom `baseQuery` wrapper around `fetchBaseQuery` that intercepts 401 results, awaits a shared refresh promise, and retries the original query

Inside the Redux store's `configureStore` middleware array using `redux-thunk` exclusively, with no relation to `baseQuery`

In `app.json`, via the `expo.extra` configuration field

In an RTK Query setup, where is the correct place to implement the single-flight token-refresh-on-401 logic?

Hardcoding the API's IP address instead of using a domain name

Using a native networking layer/library (e.g., `react-native-ssl-pinning`, or a custom Expo Module wrapping `URLSession`/`OkHttp` pinning config) that validates the server's certificate or public key hash against a pinned value before completing the TLS handshake

Setting `rejectUnauthorized: false` in the fetch configuration

Storing the API's SSL certificate in `AsyncStorage` and comparing it manually after each response

Which approach correctly implements certificate pinning for API calls handling PHI in a React Native app?

Питання 15 з 15