Методы аутентификации для REST API
Способов, с помощью которых мы можем реализовать аутентификацию для нашего REST API множество, но ниже хочу рассмотреть основные из них, которые встречались за мою практику.
Аутентификация это процесс, когда пользователь предоставляет REST API серверу свои учётные данные для проверки "личности". В нашем случае, пользователь REST API - приложение в телефоне/планшете/ПК, или же веб-приложение, или даже REST API Client на другом сервере, для примера, реализованный через гем HTTParty для Ruby или стандартный пакет net/http для Golang. А учётные данные это имя и пароль, или же приватный ключ, по которым происходит идентификация пользователя. Пройдя аутентификацию, пользователь может использовать ресурсы, который предоставляет REST API. Процесс определения, может ли пользователь использовать нужный ему ресурс, называется авторизацией. В некоторых случаях эти два процесса неразрывно связаны, поэтому многие их путают.
Basic Authentication
Этот метод считается устаревшим из-за уязвимостей в безопасности, но он самый простой в использовании. Он предполагает передачу имени пользователя и пароля в заголовке запроса. Эти данные "кодируются" с использованием Base64, который представляет собой метод "кодирования", преобразующий данные в набор ASCII-символов для удобства передачи по протоколу HTTP. Данный метод обязует нас использовать HTTPS, так как данные могут быть легко перехвачены.
REST API клиент шлет в заголовках запроса следующее значение: Authorization: Basic rT23xHrTDfY21txNv==. REST API сервер парсит этот заголовок, декодируя его и проверяя, что переданное значение имени пользователя и его пароля совпадает с тем, что хранится на сервере.
На моей практике, данный метод использовали для различных админ-панелей или внутренних инструментов, которые находятся в закрытом контуре. К примеру, админка Sidekiq, доступ к которой обычно настраивается на уровне middleware.
Bearer Authentication
В целом, данный метод чем-то схож с Basic, но предоставляет двухэтапную(не путать с двухфакторной) аутентификацию. Не хочется повторятся, но этот метод так же необходимо использовать только совместно с HTTPS.
На первом этапе/запросе, как и в случае с Basic, REST API клиент шлет имя и пароль пользователя. REST API сервер идентифицирует и авторизирует клиента, и в ответ отдает сгенерированный Bearer токен. Во всех последующих запросах к ресурсам REST API сервера, клиент передает значение этого токена в заголовке запроса: Authorization: Bearer 870a52f56df3ecee52db1f. Обычно токен имеет время жизни, в течении которого он остается валидным, в этом и заключается главная фишка данного метода. Клиент не передает в каждом запросе значения имени пользователя и пароля, а только единожды. После истечения времени жизни, REST API клиент должен запросить новый Bearer токен. В зависимости от архитектуры REST API, запрос может быть выполнен стандартным путем(передачей имени/пароля), либо с использованием так называемого refresh токена. Подробнее об механизме использования refresh токена можно поглядеть в такой реализации варианта Bearer-токена, как JWT(JSON Web Token).
По моему мнению, данный метод, особенно в варианте JWT, является наиболее распространенным в современных реализации REST API.
Personal Access Token(PAT) Authentication
На стороне REST API сервера генерируется и сохраняется ключ, который передается, можно сказать вручную, пользователю(к примеру, он может получить его по почте, либо взять значение в админ-панеле сервиса).
Затем пользователь устанавливает его значение в REST API клиенте, и в каждом запросе оно передается в заголовках: Authorization: dXNlcjpzZWNyZXQ. REST API сервер парсит этот заголовок, и сравнивает с тем значением, что хранится на сервере. Токен обычно имеет время жизни, и по истечению его срока, пользователь должен заново сгенерировать новый PAT и установить его значение на клиенте.
Этот метод довольно прост в реализации, но так как значение токена передается в открытом виде, его можно использовать только совместно с HTTPS. Обычно с помощью PAT реализуется взаимодействие между двумя сервисами, когда REST API клиент располагается на сервере и токен скрыт от посторонних глаз.