У меня есть приложение Play Framework, выступающее в роли внутреннего сервера, предоставляющего набор REST API.
На стороне клиента у меня есть приложение AngularJS, которое вызывает API с внутреннего сервера через AJAX.
В настоящее время я использую решение, основанное на механизме маркера сеанса.
Это означает, что каждый раз, когда пользователь успешно входит в систему, на стороне клиента извлекается файл cookie, содержащий маркер аутентификации.
Затем при каждом запросе файл cookie значение (токен аутентификации), предоставленное запросом клиента, извлекается на сервере, и, если он действителен, выполняется запрос.
Теперь я хочу использовать OAuth 2.0. Причины есть? :
- Это отличный стандартный способ защитить API, избегая использования хранилища данных (Memcached) для хранения токенов аутентификации на стороне сервера, как я сейчас предоставляю.
- Я хочу обеспечить лучшую безопасность, чем единственный файл cookie, предоставив некоторые client_secret и одноразовые номера, чтобы избежать некоторых повторных атак и т. д.
- Я хочу ограничить количество клиентов, способных вызывать даже общедоступный REST API, который я предоставляю, то есть API, который позволяет анонимный вызов, например, список элементов.
Дело в том, что я не привлекаю третью сторону, так как все защищенные ресурсы находятся на моей собственной ответственности.
Я наткнулся на этот статья, объясняющая, как защитить внутренний REST API с помощью OAuth 2.0, реализующего двухстороннее соединение вместо трехстороннего, как обычно.
Однако я не могу понять, как поток Client Credentials может аутентифицировать конкретного пользователя при вызове REST API, для которого требуется аутентификация пользователя.
Действительно, поток учетных данных клиента, по-видимому, основан на глобальных ключах client_id, client_secret (глобальных для приложения, поэтому в моем случае для моего приложения Javascript) и, следовательно, недостаточно специфичен для нацеливания на конкретного пользователя и управления его конкретными правами.
Любая помощь будет здорово.
