Какие знаешь способы передачи токена при выполнении сетевого запроса?

Способы передачи токена аутентификации в сетевых запросах

В современной Android-разработке существует несколько ключевых способов передачи токенов аутентификации при выполнении сетевых запросов. Выбор конкретного метода зависит от требований безопасности, архитектуры API и стандартов, используемых бэкендом.

1. Заголовок Authorization (наиболее распространенный)

Самый стандартный и рекомендуемый способ - использование заголовка Authorization с указанием типа токена:

// Пример с использованием Retrofit
interface ApiService {
    @GET("user/profile")
    suspend fun getUserProfile(
        @Header("Authorization") token: String
    ): UserProfile
}

// Использование
val token = "Bearer $accessToken"
apiService.getUserProfile(token)

// Или через Interceptor в OkHttpClient
val client = OkHttpClient.Builder()
    .addInterceptor { chain ->
        val request = chain.request().newBuilder()
            .addHeader("Authorization", "Bearer $accessToken")
            .build()
        chain.proceed(request)
    }
    .build()

Преимущества:

• Стандартизированный подход (RFC 6750)
• Поддержка на стороне бэкенда из коробки
• Легко добавляется через интерцепторы

2. Кастомные заголовки

Некоторые API требуют использование кастомных заголовков:

// Пример с кастомным заголовком
@GET("data")
suspend fun fetchData(
    @Header("X-Auth-Token") token: String,
    @Header("X-API-Key") apiKey: String
): Response<Data>

Когда использовать:

• При работе с legacy-системами
• Когда бэкенд требует специфичные названия заголовков
• Для дополнительных ключей API вместе с основным токеном

3. Параметры запроса (Query Parameters)

Передача токена через query-параметры, хотя и менее безопасная:

@GET("user/data")
suspend fun getUserData(
    @Query("access_token") token: String
): UserData

Недостатки:

• Токен виден в URL (попадает в логи сервера, браузера)
• Небезопасно при сохранении истории
• Не соответствует RESTful-принципам

4. Тело запроса (Request Body)

Для POST/PUT запросов токен может передаваться в теле:

@POST("auth/refresh")
suspend fun refreshToken(
    @Body request: RefreshTokenRequest
): AuthResponse

data class RefreshTokenRequest(
    val refresh_token: String,
    val client_id: String
)

Применение:

• При обновлении токенов (refresh token flow)
• В OAuth 2.0 flows
• Для специфичных операций аутентификации

5. Cookies

Автоматическая отправка токена через cookies:

// Настройка OkHttpClient с CookieJar
val cookieJar = PersistentCookieJar(
    SetCookieCache(),
    SharedPrefsCookiePersistor(context)
)

val client = OkHttpClient.Builder()
    .cookieJar(cookieJar)
    .build()

Особенности:

• Автоматическая отправка сервером через Set-Cookie
• Поддержка сессий
• Требует осторожности из-за CSRF-уязвимостей

6. Комбинированные подходы

На практике часто используется комбинация методов для разных сценариев:

// Пример комплексной реализации
class AuthInterceptor(
    private val tokenManager: TokenManager
) : Interceptor {
    
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        
        val newRequest = when {
            request.url.encodedPath.contains("/auth/refresh") -> {
                // Для refresh используем тело запроса
                request
            }
            tokenManager.hasValidToken() -> {
                // Для обычных запросов - заголовок Authorization
                request.newBuilder()
                    .addHeader("Authorization", "Bearer ${tokenManager.getAccessToken()}")
                    .build()
            }
            else -> request
        }
        
        return chain.proceed(newRequest)
    }
}

Рекомендации по безопасности:

1. Используйте HTTPS для всех запросов с токенами
2. Реализуйте автоматическое обновление токенов через интерцепторы:

class TokenRefreshInterceptor(
    private val authRepository: AuthRepository
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val response = chain.proceed(chain.request())
        
        if (response.code == 401) {
            // Попытка обновить токен и повторить запрос
            val newToken = authRepository.refreshToken()
            if (newToken != null) {
                val newRequest = chain.request().newBuilder()
                    .header("Authorization", "Bearer $newToken")
                    .build()
                return chain.proceed(newRequest)
            }
        }
        return response
    }
}

1. Храните токены безопасно - используйте EncryptedSharedPreferences или Security Library
2. Реализуйте механизм логаута при истечении refresh token
3. Избегайте хардкода токенов и чувствительных данных в коде

Выбор подхода:

• Для REST API - предпочтительнее заголовок Authorization: Bearer <token>
• Для GraphQL - обычно также используется заголовок Authorization
• Для WebSocket соединений - токен передается при установке соединения или в первых сообщениях
• Для Server-Sent Events - через заголовки или параметры URL

В современных Android-приложениях рекомендуется использовать OkHttp Interceptors для централизованной обработки добавления токенов, что обеспечивает чистоту кода, единую точку модификации запросов и возможность реализации сложной логики (авто-обновление токенов, ретраи при 401 ошибках и т.д.).