🔐 Путеводитель по аутентификации: от Cookies до OAuth 2.0
🔐 Путеводитель по аутентификации: от 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: Прямая передача логина/пароля (используется только в доверенных приложениях). #backend #security #jwt #oauth #webdev ♻️ Сделай репост, чтобы помочь другим. 👉 @Bookflow