Вы можете использовать Протокол OpenID Connect (на основе OAuth 2 и JSON Web Tokens).
Но это может быть излишним для большинства сценариев, потому что JWT имеет смысл только в том случае, если вам нужно масштабировать «сеанс» на нескольких серверах и / или балансировщиках нагрузки в серверной инфраструктуре.Также простой выход из системы невозможен при использовании токенов на основе JWT.Если вы начнете управлять черными списками JWT на стороне сервера, API больше не будет оставаться без состояния.
Я думаю, что очень длинный API-токен в заголовке HTTP, например, UUID,будет безопасным и достаточно хорошим в большинстве случаев.
Заголовок запроса HTTP Authorization
содержит учетные данные для проверки подлинности пользовательского агента на сервере, обычно после того, как сервер ответил статусом 401 Unauthorized
иЗаголовок WWW-Authenticate.
Синтаксис:
Authorization: <type> <credentials>
Базовая аутентификация
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
На основе токена
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9...TJVA95OrM7E20RMHrHDcEfxjoYZgeFONFh7HgQ
UUID в качестве токена
Authorization: Bearer bb79dfb5-17fd-4ebc-acd5-548e308e5f9a
Также убедитесь, что все запросы API зашифрованы по протоколу SSL (HTTPS).
PS: Если вы просто хотите защитить свой API для веб-приложения , классический Session
с Cookies
также достаточно хорош и очень безопасен.