Попрактиковаться во взломах
Об аутентификации
Cookie-based authentication, обычный сценарий:
- клиент отправляет на host.com/login имя и пароль
- сервер создаёт сессию и SESSIONID
- сервер проверяет валидность имени и пароля
- если всё хорошо, записывает в сессию признак, что клиент аутентифицировался
- отправляет клиенту результат и сессионную куку (SESSIONID)
- клиент в следующем значимом запросе отправляет эту куку
- сервер поднимает сессию по куке и проверяет есть ли в ней признак аутентификации, то есть отправлял ли клиент валидные аутентификационные данные
- если всё ок, то запрос выполняется
Token-based authentication (JSON Web-Tokens, OAuth, OpenID):
- на метод логина отправляем данные (по сути это не логин, а создание нового токена, POST /tokens, если удобно).
- проверяем логин-пароль, если все ок — отдаем сущность нового токена, которым затем Клиент подписывает каждый запрос.
-
при последующих запросах просто проверяем наличие переданного токена в HEADERе запроса токена, достаём из токена идентификатор пользователя.
это не ломает stateless, токен такая же сущность, что и статья и другие, и если они не найдены — возвращаем ошибку, либо работаем с ними, если все ок.
- чтобы сделать логаут — DELETE /tokens/{token}
Cookie sessionid представляет из себя строку, определяемую логикой сервера, в то время как token генерируется согласно стандарту.
Сервер может делиться токенами с третьей стороной (third party applications)