Путеводитель по аутентификации: от Cookies до OAuth 2.0
Разбираться в способах входа пользователя в систему можно бесконечно, но эта шпаргалка отлично раскладывает всё по полочкам. Давайте разберем эволюцию методов «узнавания» пользователя.
1. WWW-Authenticate (Basic Auth)
Самый древний способ. Браузер запрашивает логин/пароль и отправляет их в каждом заголовке.
• Минус: Невозможно нормально управлять жизненным циклом сессии (сложно разлогиниться).
2. Session-cookie
Классика веба. После входа сервер создает сессию в базе, а браузеру отдает Session ID в куках.
• Проблема: Плохо масштабируется и «не дружит» с мобильными приложениями, которые не всегда умеют работать с куками так же, как браузеры.
3. Token & JWT
Чтобы не дергать базу данных каждый раз, придумали токены.
• Token: Обычная строка, которую проверяет отдельный сервис валидации.
• JWT (JSON Web Token): «Умный» токен. Он содержит внутри хедер, полезную нагрузку (данные пользователя) и подпись. Серверу не нужно лезть в базу, чтобы проверить его валидность - достаточно проверить подпись.
4. SSO (Single Sign-On)
Когда у вас много сайтов (a.com, b.com), а логин один. Центральный сервис аутентификации (CAS) берет на себя проверку личности и перенаправляет пользователя между ресурсами без повторного ввода пароля.
5. OAuth 2.0
Стандарт для предоставления доступа сторонним приложениям (например, «Войти через Google»). Основные сценарии:
• Authorization Code: Самый безопасный (через браузер и сервер).
• Client Credentials: Для общения между двумя серверами.
• Implicit Grant: Упрощенный путь для мобильных и JS-приложений (сейчас считается менее безопасным).
• Password Grant: Прямая передача логина/пароля (используется только в доверенных приложениях).
Разбираться в способах входа пользователя в систему можно бесконечно, но эта шпаргалка отлично раскладывает всё по полочкам. Давайте разберем эволюцию методов «узнавания» пользователя.
1. WWW-Authenticate (Basic Auth)
Самый древний способ. Браузер запрашивает логин/пароль и отправляет их в каждом заголовке.
• Минус: Невозможно нормально управлять жизненным циклом сессии (сложно разлогиниться).
2. Session-cookie
Классика веба. После входа сервер создает сессию в базе, а браузеру отдает Session ID в куках.
• Проблема: Плохо масштабируется и «не дружит» с мобильными приложениями, которые не всегда умеют работать с куками так же, как браузеры.
3. Token & JWT
Чтобы не дергать базу данных каждый раз, придумали токены.
• Token: Обычная строка, которую проверяет отдельный сервис валидации.
• JWT (JSON Web Token): «Умный» токен. Он содержит внутри хедер, полезную нагрузку (данные пользователя) и подпись. Серверу не нужно лезть в базу, чтобы проверить его валидность - достаточно проверить подпись.
4. SSO (Single Sign-On)
Когда у вас много сайтов (a.com, b.com), а логин один. Центральный сервис аутентификации (CAS) берет на себя проверку личности и перенаправляет пользователя между ресурсами без повторного ввода пароля.
5. OAuth 2.0
Стандарт для предоставления доступа сторонним приложениям (например, «Войти через Google»). Основные сценарии:
• Authorization Code: Самый безопасный (через браузер и сервер).
• Client Credentials: Для общения между двумя серверами.
• Implicit Grant: Упрощенный путь для мобильных и JS-приложений (сейчас считается менее безопасным).
• Password Grant: Прямая передача логина/пароля (используется только в доверенных приложениях).