Что касается веб-приложения, то запрос веб-приложения должен иметь состояние, сеанс является наиболее распространенным способом получения состояния.
И когда мы рассматриваем REST API запросы предпочтительны, чтобы быть без сохранения состояния, но для аутентификации и идентификации пользователя или клиента есть много способов, как упомянуто OP.
Некоторые из наиболее распространенных способов аутентификации в REST API описаны ниже
1. Базовая аутентификация
При обычной аутентификации пользователь отправляет свои учетные данные, закодированные кодировщиком base64.
Учетные данные отправляются в заголовке авторизации с префиксом Basic, как указано ниже.
"Basic "+ encodeUsingBase64(username+":"+password)
Если ваш REST API защищен базовой аутентификацией, пользователь, не являющийся частью приложения (пользователь, которого нет в базе данных сервера), не сможет получить доступ к защищенным ресурсам.
В идеале базовая аутентификация предназначена только для пользователей приложений
2. Токен JWT / Bearer
Веб-токен JSON (JWT) - это открытый стандарт (RFC 7519), в котором сервер совместно использует токен с цифровой подписью с клиентом, его могут использовать как пользователи приложения, так и не пользователи приложения с сервером. боковая логика, которая извлекает информацию о пользователе из полезной нагрузки токена и проверяет ее записи в базе данных для авторизации. Здесь с JWT вариант использования не ограничен, в некоторых реализациях полезная нагрузка может также содержать информацию авторизации. Single Sign On - это функция, которая в настоящее время широко использует JWT.
По сравнению с базовой аутентификацией
Базовая аутентификация - это шаг аутентификации, на который отправляются полные учетные данные (включая пароль)в каждом запросе.
JWT - это шаг после аутентификации, когда аутентифицированный пользователь получает подписанный токен, который не содержит информацию о пароле.
3. Ключ API
Он не имеет стандартов, это может быть случайно сгенерированная строка, выданная пользователям API. Вариант использования будет отличаться для разных эмитентов. Это хорошо обсуждается здесь
4. Oauth2.0
Oauth2 - это другая категория. В одном предложении речь идет не о защите всех прикладных API, а о предоставлении доступа к user resource к third party applications с consent of user.
, состоящему в основном из 4 частей. Возьмем пример Facebook
1. Сервер авторизации [Facebook]
2. Сервер ресурсов [Facebook и ресурс будут вашим профилем]
3. Клиент [Переполнение стека, Quora, Candy crush, Subway Surfer и т. Д.]
4. Владелец ресурса [Вы (если аутентифицирован)]
Сервер ресурсов может состоять как из защищенного, так и из незащищенного API. Для доступа к защищенному API клиента необходим access_token, который выдается сервером авторизации. Выданный access_token является случайной строкой и также сохраняется в базе данных сервера авторизации вместе с соответствующим пользователем, область действия (read, read_profile_info, write).
Здесь владелец ресурса (Вы) дает согласие насервер авторизации для предоставления access_token области действия (read, read-profile, post-to-my-timeline и т. д.) Клиенту (Quora, StackOverflow, Candy-Crush и т. д.)
Преимуществоиз oauth2.0 - access_token получит аутентификацию и авторизацию. Так что будет полезно предоставить определенную область для access_token.
(например, переполнение стека приводит к доступу к основной информации профиля, конфеты крошка обращается к дополнительной информации, включая объем публикации от вашего имени) - срок службы access_token, grant_typeof refresh_token.
Срок действия маркеров доступа ограничен. Если клиентскому приложению требуется доступ к ресурсу после срока действия одного токена доступа, оно может получить токен обновления. Токен обновления позволяет клиентскому приложению получать новые токены доступа.
Типы предоставления: (код авторизации, неявный, пароль, клиентский доверенный, токен обновления)
Примечание: Сервер Oauth2 Auth не только для таких приложений, как Facebook и Google, но и для вашего приложения может быть настроен сервер oauth2, и вы можете предоставить своим клиентам access_token (для интеграции вашего API с их приложением) с различной областью действия, срок службы которого зависит от подписки /лицензия.
5. Digest auth
Я не работал над digest auth. Для получения более подробной информации см. Эту ветку
Основы безопасности транспортного уровня
SSL Любой изПриведенная выше проверка подлинности относится к безопасности транспортного уровня (SSL), чтобы гарантировать, что учетные данные / токен, которые вы передаете в последующих запросах, не записываются в виде простого текста.
X.509 (имеет преимущество перед SSL) SSL-сертификат отправляется сервером клиенту (любой клиент, отправляющий запрос на сервер, получает копию SSL. Ограничений нет, любой клиент может получить SSL-сертификат).
Но в случае X.509 клиентский сертификат создается с использованием SSL-сертификата сервера и тайно передается клиенту. Клиент использует сертификат X.509 для связи с сервером. Здесь следует отметить один важный момент: для разных клиентов будут генерироваться разные клиентские сертификаты для идентификации каждого клиента. X.509 гарантирует, что
Безопасность (у кого нет сертификата клиента, не могут получить доступ к API)
Идентификация (сервер может идентифицироватьклиент на основании предмета сертификата)