How to Store Authentication Tokens Securely in Flutter: Complete Guide

Authentication is one of the most important parts of modern mobile application development. Whether you are building an e-commerce app, banking application, social media platform, or enterprise dashboard, you need a secure way to manage user authentication.

Most Flutter applications use authentication tokens, such as access tokens and refresh tokens, to identify users and authorize API requests.

However, storing these tokens incorrectly can expose sensitive user information, allow unauthorized access, and compromise application security.

For example, storing an access token in SharedPreferences or hardcoding an API token directly into your Flutter source code can create unnecessary security risks.

In this guide, you will learn how to securely store authentication tokens in Flutter using flutter_secure_storage, manage access and refresh tokens, integrate secure storage with Dio, handle token expiration, and implement secure logout functionality.

We will also cover common security mistakes and practical techniques for protecting authentication data in production Flutter applications.

1. Understanding Authentication Tokens in Flutter

An authentication token is a credential issued by an authentication server after a user successfully logs in.

Instead of sending the user’s email and password with every API request, the application sends an authentication token to prove that the user has already authenticated.

A typical token-based authentication flow works as follows:

1. The user enters their email and password.
2. The Flutter application sends the credentials to the authentication server.
3. The server validates the credentials.
4. The server returns an access token and, optionally, a refresh token.
5. The Flutter application stores the tokens securely.
6. The application includes the access token in subsequent protected API requests.
7. When the access token expires, the application uses the refresh token to request a new access token.

For example, a successful login API response might look like this:

JSON

{
  "success": true,
  "message": "Login successful",
  "data": {
    "access_token": "eyJhbGciOiJIUzI1NiIs...",
    "refresh_token": "refresh_token_value",
    "expires_in": 900
  }
}

The access token is used to access protected resources, while the refresh token allows the application to obtain a new access token without requiring the user to log in again.

Both tokens should be treated as sensitive credentials.

Access Token vs Refresh Token

Although access tokens and refresh tokens are often used together, they serve different purposes.

|
Feature

|

Access Token

|

Refresh Token

|
| — | — | — |
|

Purpose

|

Authorize protected API requests

|

Obtain a new access token

|
|

Typical lifetime

|

Short-lived

|

Longer-lived

|
|

Sent with API requests

|

Yes, when required

|

Only to the authentication refresh endpoint

|
|

Storage

|

Secure storage or protected in-memory storage

|

Secure persistent storage

|
|

Exposure risk

|

Unauthorized access until expiration or revocation

|

Potentially prolonged unauthorized access

|
|

Expiration handling

|

Renew using a refresh token

|

Require reauthentication when invalid or expired

|

Access tokens are commonly implemented as JSON Web Tokens (JWTs), although applications can also use opaque tokens.

A JWT typically contains three encoded sections: a header, a payload, and a signature.

The payload can be decoded without knowing the signing key. Therefore, you should never assume that a JWT is encrypted or that its contents are confidential.

Important: A JWT’s signature helps verify its integrity and authenticity. It does not hide the information contained in the token.

2. Why Secure Token Storage Matters

Authentication tokens are often bearer credentials. Anyone who obtains a valid bearer token may be able to access the resources associated with that token.

Consider an application that stores its authentication token in ordinary application preferences.

If an attacker obtains a readable copy of those preferences through a compromised device, an insecure backup, or another vulnerability, the token may be exposed.

The attacker could potentially use that token to make authenticated requests without knowing the user’s password.

Secure storage reduces this risk by using platform-specific mechanisms designed to protect sensitive application data.

However, secure storage does not make an application completely immune to token theft. A compromised device, malicious application code, insecure logging, or a vulnerable backend can still expose authentication credentials.

A secure authentication implementation therefore requires both protected storage and proper token lifecycle management.

3. Where Should You Store Authentication Tokens in Flutter?

Flutter provides several ways to persist application data, but not every storage mechanism is appropriate for authentication credentials.

|
Storage method

|

Recommended for tokens?

|

Reason

|
| — | — | — |
|

SharedPreferences

|

No

|

General-purpose preferences are not designed for secret storage.

|
|

SQLite

|

Not by default

|

Standard database storage does not provide dedicated credential protection.

|
|

Hive

|

Not by default

|

Requires additional encryption and secure key management.

|
|

FlutterSecureStorage

|

Yes

|

Uses platform-specific secure storage mechanisms.

|
|

In-memory variables

|

Yes, for temporary use

|

Tokens are not persisted to ordinary application storage, but remain exposed to runtime compromise.

|

For most Flutter applications, flutter_secure_storage is a practical choice for storing authentication tokens that must persist across application restarts.

You can also keep short-lived access tokens in memory while storing refresh tokens securely on the device.

This reduces persistent exposure of access tokens, although it requires careful session restoration when the application restarts.

Why SharedPreferences is not suitable for authentication tokens

SharedPreferences is designed to store simple application preferences, such as:

• Selected application theme.
• Preferred language.
• Onboarding completion status.
• Non-sensitive user interface settings.

It is not a dedicated secure credential store.

Avoid storing authentication tokens like this:

dart

final prefs = await SharedPreferences.getInstance();

await prefs.setString(
  'access_token',
  accessToken,
);

Instead, use a storage solution specifically designed to protect sensitive data.

4. Install FlutterSecureStorage

The flutter_secure_storage package provides a convenient API for storing sensitive information using native platform security mechanisms.

On Android, recent versions use Android Keystore-backed key protection and encrypted storage. On iOS, the package uses Apple’s Keychain.

The exact implementation and supported options depend on the package version and target platform.

Flutter package

+1

Step 1: Add the dependency

Open your Flutter project and run:

Bash

flutter pub add flutter_secure_storage

For the API integration examples later in this guide, also install Dio:

Bash

flutter pub add dio

You can find the packages here:

• flutter_secure_storage on pub.dev 
• Dio on pub.dev

Using flutter pub add installs a compatible package version and updates your project’s pubspec.yaml.

Step 2: Import the package

dart

import 'package:flutter_secure_storage/flutter_secure_storage.dart';

Step 3: Initialize secure storage

Create an instance of FlutterSecureStorage:

dart

const storage = FlutterSecureStorage();

You can now use this instance to securely write, read, and delete authentication tokens.

The following examples target Android and iOS. Flutter Web requires a separate security assessment because browser storage and browser-based authentication have different threat models.

5. Create a Secure Token Storage Service

Instead of accessing secure storage directly from every screen or controller, create a dedicated service to manage authentication tokens.

This approach keeps your authentication logic organized and makes it easier to update the storage implementation later.

A suitable project structure is:

lib/
├── app/
│   └── utils/
│       └── token_storage_service.dart
│
├── features/
│   └── auth/
│       ├── controllers/
│       │   └── auth_controller.dart
│       ├── models/
│       │   └── auth_tokens.dart
│       ├── screens/
│       │   └── login_screen.dart
│       └── services/
│           └── auth_service.dart
│
├── network/
│   └── api_client.dart
│
└── main.dart

This separates secure token storage, authentication requests, network configuration, and user interface logic.

Step 1: Create the token storage service

Create the following file:

lib/app/utils/token_storage_service.dart

dart

import 'package:flutter_secure_storage/flutter_secure_storage.dart';

class TokenStorageService {
  TokenStorageService._();

  static final TokenStorageService instance =
      TokenStorageService._();

  static const FlutterSecureStorage _storage =
      FlutterSecureStorage();

  static const String _accessTokenKey = 'access_token';
  static const String _refreshTokenKey = 'refresh_token';

  // Save the access token.
  Future<void> saveAccessToken(String token) async {
    await _storage.write(
      key: _accessTokenKey,
      value: token,
    );
  }

  // Retrieve the access token.
  Future<String?> getAccessToken() async {
    return await _storage.read(
      key: _accessTokenKey,
    );
  }

  // Save the refresh token.
  Future<void> saveRefreshToken(String token) async {
    await _storage.write(
      key: _refreshTokenKey,
      value: token,
    );
  }

  // Retrieve the refresh token.
  Future<String?> getRefreshToken() async {
    return await _storage.read(
      key: _refreshTokenKey,
    );
  }

  // Save both tokens.
  Future<void> saveTokens({
    required String accessToken,
    required String refreshToken,
  }) async {
    await saveAccessToken(accessToken);
    await saveRefreshToken(refreshToken);
  }

  // Delete the access token.
  Future<void> deleteAccessToken() async {
    await _storage.delete(
      key: _accessTokenKey,
    );
  }

  // Delete the refresh token.
  Future<void> deleteRefreshToken() async {
    await _storage.delete(
      key: _refreshTokenKey,
    );
  }

  // Remove authentication tokens.
  Future<void> clearTokens() async {
    await deleteAccessToken();
    await deleteRefreshToken();
  }

  // Check whether an access token exists.
  Future<bool> hasAccessToken() async {
    final token = await getAccessToken();

    return token != null && token.isNotEmpty;
  }
}

The service provides a single place to manage authentication credentials.

It also prevents your login screen, dashboard, and API services from implementing different token storage mechanisms.

Important: Saving two values separately is not an atomic transaction. If the second write fails, the first value may already have been saved. For applications requiring strict session consistency, consider storing a validated token pair as one serialized record or implementing explicit recovery for incomplete writes.

Step 2: Save authentication tokens

After a successful login, save the access token and refresh token:

dart

final tokenStorage = TokenStorageService.instance;

await tokenStorage.saveTokens(
  accessToken: accessToken,
  refreshToken: refreshToken,
);

Because secure storage operations are asynchronous, use await to ensure that the tokens are saved before proceeding with authentication-dependent operations.

Step 3: Retrieve a stored token

When making an authenticated API request:

dart

final token = await TokenStorageService.instance
    .getAccessToken();

if (token != null && token.isNotEmpty) {
  // Use the token for an authenticated request.
}

Avoid printing the retrieved token in application logs.

For example, do not use:

dart

print('Access Token: $token');

Debugging tools, crash reports, and shared log files can accidentally expose sensitive authentication information.

Step 4: Delete tokens

When the user logs out:

dart

await TokenStorageService.instance.clearTokens();

This removes the two authentication token entries managed by the service.

It does not delete unrelated secure storage entries, such as saved biometric preferences or other application credentials.

6. Store Tokens After a Successful Login

Now that the secure storage service is ready, you can integrate it with your authentication API.

Assume your backend provides the following endpoint:

POST https://api.example.com/auth/login

The request body contains the user’s email and password:

JSON

{
  "email": "user@example.com",
  "password": "user_password"
}

After successful authentication, the server returns:

JSON

{
  "access_token": "your_access_token",
  "refresh_token": "your_refresh_token"
}

The following example demonstrates how to send a login request using Dio and securely store the returned tokens.

Create an authentication service

File: lib/features/auth/services/auth_service.dart

dart

import 'package:dio/dio.dart';

import '../../../app/utils/token_storage_service.dart';

class AuthService {
  final Dio _dio = Dio(
    BaseOptions(
      baseUrl: 'https://api.example.com',
      connectTimeout: const Duration(seconds: 15),
      receiveTimeout: const Duration(seconds: 15),
      headers: {
        'Content-Type': 'application/json',
      },
    ),
  );

  final TokenStorageService _tokenStorage =
      TokenStorageService.instance;

  Future<bool> login({
    required String email,
    required String password,
  }) async {
    try {
      final response = await _dio.post(
        '/auth/login',
        data: {
          'email': email,
          'password': password,
        },
      );

      if (response.statusCode != 200) {
        return false;
      }

      final data = response.data as Map<String, dynamic>;

      final accessToken = data['access_token'] as String?;
      final refreshToken = data['refresh_token'] as String?;

      if (accessToken == null ||
          accessToken.isEmpty ||
          refreshToken == null ||
          refreshToken.isEmpty) {
        return false;
      }

      await _tokenStorage.saveTokens(
        accessToken: accessToken,
        refreshToken: refreshToken,
      );

      return true;
    } on DioException {
      // Handle authentication or network errors.
      return false;
    }
  }
}

This example assumes the backend returns both tokens at the top level of the response.

If your API returns tokens inside a data object, update the parsing logic accordingly.

The code also assumes a refresh-token-based authentication system. If your backend uses another authentication mechanism, adapt the service to match its actual response and session lifecycle.

For production applications, distinguish invalid credentials from network failures and storage errors so users receive appropriate feedback. Avoid exposing sensitive server response data in error messages.

Call the login service from a GetX controller

If your Flutter application uses GetX, you can keep the login request separate from the user interface.

File: lib/features/auth/controllers/auth_controller.dart

dart

import 'package:get/get.dart';

import '../services/auth_service.dart';

class AuthController extends GetxController {
  final AuthService _authService = AuthService();

  final RxBool isLoading = false.obs;

  Future<void> login({
    required String email,
    required String password,
  }) async {
    if (isLoading.value) return;

    isLoading.value = true;

    try {
      final success = await _authService.login(
        email: email,
        password: password,
      );

      if (success) {
        Get.offAllNamed('/home');
      } else {
        Get.snackbar(
          'Login Failed',
          'Unable to sign in. Please check your details.',
        );
      }
    } catch (_) {
      Get.snackbar(
        'Error',
        'Something went wrong. Please try again.',
      );
    } finally {
      isLoading.value = false;
    }
  }
}

The controller manages the loading state and navigation, while the authentication service handles API communication and token storage.

This separation makes authentication easier to maintain and test.

7. Automatically Attach Access Tokens to API Requests Using Dio

After saving the access token, the next step is to attach it to protected API requests.

Most bearer-token authentication systems expect an HTTP authorization header in this format:

http

Authorization: Bearer your_access_token

You could manually retrieve and attach the token before every request, but this creates repetitive code and increases the possibility of forgetting authentication headers.

A better approach is to use a Dio interceptor.

Dio interceptors allow you to inspect or modify requests before they are sent.

Dart package

Create a centralized API client

File: lib/network/api_client.dart

dart

import 'package:dio/dio.dart';

import '../app/utils/token_storage_service.dart';

class ApiClient {
  ApiClient._();

  static final ApiClient instance = ApiClient._();

  final TokenStorageService _tokenStorage =
      TokenStorageService.instance;

  late final Dio dio = _createDio();

  Dio _createDio() {
    final client = Dio(
      BaseOptions(
        baseUrl: 'https://api.example.com',
        connectTimeout: const Duration(seconds: 15),
        receiveTimeout: const Duration(seconds: 15),
      ),
    );

    client.interceptors.add(
      InterceptorsWrapper(
        onRequest: (options, handler) async {
          try {
            final accessToken =
                await _tokenStorage.getAccessToken();

            if (accessToken != null &&
                accessToken.isNotEmpty) {
              options.headers['Authorization'] =
                  'Bearer $accessToken';
            }

            handler.next(options);
          } catch (error) {
            handler.reject(
              DioException(
                requestOptions: options,
                error: error,
                message: 'Unable to access authentication storage',
              ),
            );
          }
        },
      ),
    );

    return client;
  }
}

Now every request made through this client will automatically include the stored access token when one exists.

Make an authenticated API request

For example, fetch the currently authenticated user’s profile:

dart

final response = await ApiClient.instance.dio.get(
  '/user/profile',
);

final userData = response.data;

You no longer need to manually retrieve the access token or construct the authorization header for each protected endpoint.

However, the interceptor above only attaches existing tokens. It does not automatically renew expired tokens.

Also, do not use this authenticated client for arbitrary external URLs. Keep it restricted to your trusted API origin to avoid accidentally sending credentials to another server.

For public endpoints and authentication operations, a separate Dio instance without the bearer-token interceptor is often preferable.

8. How to Handle Expired Authentication Tokens in Flutter

Access tokens should generally have a limited lifetime.

For example, your backend might issue an access token that expires after 15 minutes and a refresh token that remains valid for several days.

When the access token expires, the server may return:

http

HTTP/1.1 401 Unauthorized

Your Flutter application can then use the refresh token to request a new access token.

A typical refresh request looks like this:

http

POST /auth/refresh
Content-Type: application/json

JSON

{
  "refresh_token": "your_refresh_token"
}

The server validates the refresh token and, if it is still valid, returns a new access token.

Some authentication systems also issue a new refresh token during this process. This is called refresh token rotation.

Implement a token refresh service

Add a refresh method to your authentication service:

dart

Future<String?> refreshAccessToken() async {
  final refreshToken =
      await _tokenStorage.getRefreshToken();

  if (refreshToken == null || refreshToken.isEmpty) {
    return null;
  }

  final response = await _dio.post(
    '/auth/refresh',
    data: {
      'refresh_token': refreshToken,
    },
  );

  final data = response.data as Map<String, dynamic>;

  final newAccessToken = data['access_token'] as String?;

  if (newAccessToken == null ||
      newAccessToken.isEmpty) {
    throw const FormatException(
      'Refresh response does not contain an access token',
    );
  }

  final newRefreshToken = data['refresh_token'] as String?;

  await _tokenStorage.saveAccessToken(newAccessToken);

  if (newRefreshToken != null &&
      newRefreshToken.isNotEmpty) {
    await _tokenStorage.saveRefreshToken(
      newRefreshToken,
    );
  }

  return newAccessToken;
}

This method reads the refresh token, requests new credentials from the backend, and saves the updated tokens.

The example assumes that your refresh endpoint may return a replacement refresh token. If your backend always rotates refresh tokens, require the new token in the response rather than treating it as optional.

Important considerations for automatic token refresh

In production, several requests might receive a 401 response at nearly the same time.

If each request independently attempts to refresh the token, your application could send multiple refresh requests using the same refresh token.

This can cause problems when the backend implements refresh token rotation.

A robust implementation should coordinate concurrent refresh attempts so that only one refresh request is active for the current session. Other requests should wait for the result and then use the updated access token.

The refresh request should use a separate Dio instance so that the authentication interceptor does not repeatedly intercept its own refresh request.

For automatic retry handling, ensure that:

• A failed request is retried at most once after successful refresh.
• A permanent refresh-token rejection ends the session.
• Temporary network failures do not automatically delete otherwise valid refresh tokens.
• A refresh started before logout cannot restore the old session.
• Non-replayable request bodies, such as upload streams, are not automatically retried without appropriate handling.

Dio supports request interception and queued interceptors, but coordinating concurrent refresh operations requires explicit session-level logic.

Dart package

For applications that need a complete refresh implementation, you can also evaluate the refresh_interceptor package . It provides shared refresh handling, refresh-token rotation support, and controlled request retries.

Always adapt the implementation to your backend’s token expiration, rotation, and revocation rules.

9. Restore the Authentication Session When the App Starts

Users generally expect to remain logged in when they close and reopen an application.

Secure storage allows authentication credentials to persist across application restarts, but the existence of a stored token does not guarantee that the user is still authenticated.

The token may have expired, been revoked, or become invalid because the user’s account was disabled.

Therefore, checking only whether an access token exists is not sufficient to establish a valid session.

Basic session restoration

Create a method to retrieve the stored access token:

dart

Future<String?> getStoredAccessToken() async {
  return await TokenStorageService.instance
      .getAccessToken();
}

During application startup, your authentication controller can read the token and determine whether session validation is required.

A recommended startup flow is:

Application starts
        |
        v
Read stored credentials
        |
        v
Credentials available?
    /         \
   No         Yes
   |           |
   v           v
Login      Validate session
Screen          |
           Session valid?
             /    \
            No    Yes
            |      |
            v      v
         Refresh  Home
         session  Screen
            |
       Refresh valid?
          /    \
         No    Yes
         |      |
         v      v
       Login   Home
       Screen  Screen

The exact validation process depends on your backend.

For example, your application might call a protected /auth/me endpoint or attempt a token refresh when the access token has expired.

Security note: Decoding a JWT and checking its expiration locally can help determine whether to attempt a refresh. It does not replace server-side validation of the token’s signature, audience, issuer, expiration, and revocation status.

The backend must remain responsible for authorizing protected operations.

10. Implement Secure Logout in Flutter

Logout should remove authentication credentials and prevent the old session from continuing to access protected resources.

Simply navigating to the login screen is not sufficient.

For example, the following code only changes the visible screen:

dart

Get.offAllNamed('/login');

If authentication tokens remain stored, the application might continue making authenticated requests using the previous user’s credentials.

Create a logout method

Add the following method to your authentication service:

dart

Future<void> logout() async {
  await _tokenStorage.clearTokens();
}

Then call it from your GetX controller:

dart

Future<void> logout() async {
  try {
    await _authService.logout();

    Get.offAllNamed('/login');
  } catch (_) {
    Get.snackbar(
      'Logout Failed',
      'Unable to clear the local session.',
    );
  }
}

For a production application, logout should also invalidate the server-side session when the backend supports token revocation.

A more complete logout process is:

1. Prevent new authenticated requests and cancel outstanding requests where appropriate.
2. Ask the backend to revoke the current refresh token or session.
3. Remove locally stored authentication credentials.
4. Clear user-specific in-memory state and sensitive cached data.
5. Navigate to the login screen.

If the device is offline, local credentials should still be cleared, while server-side revocation may need separate handling.

Also, a token refresh operation that began before logout must not be allowed to write new credentials after logout. A session identifier or generation counter can help prevent this race condition.

11. Configure Secure Storage for Android and iOS

Although flutter_secure_storage provides a common Flutter API, its underlying storage mechanisms differ across platforms.

Understanding the platform configuration is important when preparing an application for production.

Android: Android Keystore and encrypted storage

Recent versions of flutter_secure_storage use Android Keystore-backed protection for encryption keys and encrypted storage for saved values.

Version 10 introduced new default cryptographic settings, including RSA-OAEP key wrapping and AES-GCM for stored data. The package also requires Android API level 23 or later.

Flutter package

The default configuration is sufficient for many ordinary mobile applications.

dart

const storage = FlutterSecureStorage(
  aOptions: AndroidOptions(),
);

You should also review your application’s backup configuration.

Disable or restrict Android backups

Android backups can create problems if encrypted application data is restored without the original encryption keys.

This can result in an error such as:

java.security.InvalidKeyException:
Failed to unwrap key

The package documentation recommends disabling automatic backup or excluding its relevant storage data from backups.

Flutter package

One option is to open:

android/app/src/main/AndroidManifest.xml

And configure the application element:

XML

<application
    android:allowBackup="false"
    ... >
</application>

This disables Android Auto Backup for the application.

However, if your application requires backups for non-sensitive user data, a more targeted backup exclusion configuration may be preferable.

For Android versions supporting data extraction rules, review both cloud backup and device-transfer behavior.

Avoid copying encrypted credential data to a new device when the required decryption keys are not transferable.

iOS: Apple Keychain

On iOS, flutter_secure_storage uses Apple’s Keychain to store sensitive data.

The Keychain provides access controls and device security integration for stored credentials.

You can configure Keychain accessibility according to your application’s requirements.

For example:

dart

const storage = FlutterSecureStorage(
  iOptions: IOSOptions(
    accessibility:
        KeychainAccessibility.first_unlock_this_device,
  ),
);

This configuration allows access after the device has been unlocked following a restart, while using a device-specific accessibility class.

It can be appropriate when you do not want stored credentials to migrate to another device through normal backup restoration.

For applications that require credentials to be accessible only while the device is unlocked, consider the appropriate unlocked accessibility configuration instead.

Choose the accessibility level according to your security requirements and whether the application needs background access to credentials.

Some iOS and macOS configurations also require appropriate Keychain entitlements. Review the package’s platform setup instructions before release.

Flutter package

12. Should You Store Access Tokens and Refresh Tokens Together?

There are two common approaches to token storage.

Approach 1: Store both tokens securely

dart

await tokenStorage.saveTokens(
  accessToken: accessToken,
  refreshToken: refreshToken,
);

This approach allows the application to restore its authentication session after restarting.

It is straightforward to implement and suitable for many mobile applications.

However, both credentials persist on the device.

Approach 2: Keep the access token in memory

An alternative is to store only the refresh token persistently and keep the access token in application memory.

For example:

dart

class SessionManager {
  String? _accessToken;

  String? get accessToken => _accessToken;

  void setAccessToken(String token) {
    _accessToken = token;
  }

  void clearAccessToken() {
    _accessToken = null;
  }
}

The refresh token remains in secure storage:

dart

await tokenStorage.saveRefreshToken(
  refreshToken,
);

When the application restarts, the in-memory access token is lost.

The application can then use the stored refresh token to request a new access token.

This approach reduces persistent storage of access tokens, although it does not protect them from every runtime attack.

For applications handling highly sensitive information, keeping short-lived access tokens in memory and refresh tokens in protected persistent storage can be a useful part of a broader security design.

The appropriate choice depends on the application’s threat model, backend authentication protocol, and session requirements.

13. Common Authentication Token Security Mistakes

Even when using secure storage, other implementation mistakes can compromise authentication.

Here are some important issues to avoid.

1. Hardcoding authentication tokens

Never place actual user authentication tokens directly in source code.

dart

const accessToken = 'actual_user_token';

Source code can be copied, inspected, or exposed through version control.

A compiled mobile application should also not be treated as a secure location for permanent API secrets.

2. Logging authentication credentials

Avoid logging tokens, passwords, or complete authentication responses.

dart

debugPrint(response.data.toString());

If the response contains an access token or refresh token, this statement may expose sensitive information.

Be particularly careful when using Dio’s logging interceptors.

Disable sensitive request and response logging in production, and redact authorization headers and authentication response fields in any logging that remains enabled.

3. Sending tokens over insecure connections

Use HTTPS for authentication and protected API requests.

dart

baseUrl: 'https://api.example.com'

Avoid sending authentication credentials over unencrypted HTTP connections.

Also, do not disable TLS certificate verification to work around development or server configuration problems.

4. Using long-lived access tokens unnecessarily

Long-lived bearer tokens can increase the period during which a stolen token remains useful.

Prefer appropriately short access-token lifetimes, supported by refresh tokens or another secure session renewal mechanism.

The backend should determine token expiration according to the application’s security and usability requirements.

5. Storing passwords instead of authentication tokens

Do not persist a user’s password merely to keep them logged in.

Use the authentication protocol’s intended session mechanism, such as refresh tokens or securely managed sessions.

If the application requires biometric reauthentication, use an appropriate platform authentication mechanism rather than storing the user’s account password for repeated login.

6. Treating client-side token deletion as server-side revocation

Deleting a token from secure storage prevents the application from retrieving it again.

However, it does not necessarily invalidate an existing copy of that token.

If the backend supports token revocation, invalidate the refresh token or session during logout and other relevant security events.

7. Sending refresh tokens with every API request

Refresh tokens should generally be sent only to the authentication server’s designated refresh or revocation endpoints.

Ordinary protected API requests should use access tokens.

Avoid including refresh tokens in URL query parameters, analytics events, or application logs.

14. Security Best Practices for Production Flutter Applications

Secure storage is only one part of a complete authentication system.

The following practices help protect authentication credentials throughout their lifecycle.

|
Security practice

|

Implementation

|
| — | — |
|

Secure persistent storage

|

Use platform-backed secure storage for sensitive credentials.

|
|

Short-lived access tokens

|

Configure expiration according to the backend’s security requirements.

|
|

Refresh token rotation

|

Replace refresh tokens when the authentication server issues new ones.

|
|

HTTPS communication

|

Require TLS for authentication and protected API requests.

|
|

Secure logout

|

Clear local credentials and revoke server-side sessions when supported.

|
|

Controlled token refresh

|

Coordinate concurrent refresh attempts and prevent refresh loops.

|
|

Safe logging

|

Redact passwords, tokens, authorization headers, and sensitive responses.

|
|

Session validation

|

Verify authentication through the backend rather than trusting local token presence.

|
|

Account switching

|

Clear previous user credentials and cached data before activating another account.

|
|

Error handling

|

Distinguish expired credentials from temporary network or storage failures.

|

Additional security considerations

For applications with stronger security requirements, consider implementing device-bound credentials, biometric authentication for sensitive actions, server-side session monitoring, and risk-based reauthentication.

However, biometric authentication should not be confused with token encryption.

A biometric prompt may restrict access to a credential or sensitive operation, but it does not automatically prevent an already-extracted bearer token from being used elsewhere.

Likewise, application obfuscation, root detection, and certificate pinning may provide additional protection in certain threat models, but none of them replaces secure token handling or backend authorization.

15. Frequently Asked Questions

Is SharedPreferences safe for storing authentication tokens in Flutter?

No. SharedPreferences is designed for general application preferences rather than secure credential storage.

Use a platform-backed secure storage solution for authentication tokens that must persist on the device.

Does FlutterSecureStorage encrypt authentication tokens?

The package uses platform-specific secure storage mechanisms. On Android, recent versions use encrypted storage with Keystore-backed key protection. On iOS, it uses Keychain.

The exact security properties depend on the package version, platform configuration, and device state.

Should I store the JWT token or only the refresh token?

Both approaches are possible.

You can store access and refresh tokens securely, or keep a short-lived access token in memory while persisting the refresh token.

The second approach reduces persistent access-token exposure but requires session restoration through the authentication server.

What happens when an access token expires?

The application can use a valid refresh token to request a new access token.

If the refresh token is invalid, expired, or revoked, the user generally needs to authenticate again.

Can FlutterSecureStorage be used on Flutter Web?

The package supports web environments, but browser-based storage has a different security model from Android Keystore and iOS Keychain.

The package’s web implementation requires HTTPS or localhost and does not provide the same protection against malicious JavaScript that native platform credential storage can provide.

Flutter package

For browser-based applications, consider a backend-managed session using appropriately configured Secure, HttpOnly, and SameSite cookies, along with suitable CSRF protections.

Do not assume that a token storage design appropriate for Android and iOS is automatically appropriate for Flutter Web.

Is FlutterSecureStorage enough to make authentication secure?

No. Secure storage protects credentials at rest, but authentication security also depends on HTTPS, backend authorization, token expiration, revocation, refresh handling, logging, and device security.

Conclusion

Secure authentication token storage is an essential part of building reliable Flutter applications.

For Android and iOS applications, flutter_secure_storage provides a practical way to protect credentials using native platform security mechanisms.

A complete authentication implementation should also manage token expiration, coordinate refresh requests, validate sessions through the backend, and clear credentials securely during logout.

By separating token storage from authentication services, controllers, and API clients, you can build a Flutter authentication system that is easier to maintain, test, and extend.

The key principle is simple: protect authentication tokens throughout their entire lifecycle, not just when saving them to the device.