OAuth: Требуется ли секрет клиента в запросе ресурса?

Question

Насколько я понимаю: секрет клиента важен в OAuth1, но больше не актуален в OAuth2.

Но, похоже, что такие компании, как Google и Twitter, требуют, чтобы секрет клиента требовался для доступа-token.

С точки зрения авторизационного сервера (например, Google, Twitter, Github ...): В какой из этих ситуаций рекомендуется / не требуется секрет клиента (*)?

• получение токена доступа из кода авторизации.
• получение нового токена доступа с помощью токена обновления.
• получение ресурса с помощью доступа.токен.

Достаточно ли требовать, чтобы он только получал токен доступа по коду авторизации, или он также должен быть зафиксирован, когда кто-то использует токен доступа для получения ресурса?

---

TLDR: В моем случае: секретный ключ клиента необходим для запроса «получить токен доступа по коду авторизации» и для запроса «получить новый токен доступа и обновитьтокен по обновлениюп».Должен ли я также запрашивать секрет клиента (требовать его), когда клиент пытается получить ресурс по токену доступа?

Answer 1

Прежде всего, все ответы на ваши вопросы спрятаны в RFC-6749. Структура авторизации OAuth 2.0 .

Ваши вопросы:

Вв какой из этих ситуаций рекомендуется использовать секрет клиента / (обязательно)?получение токена доступа из кода авторизации.

См. раздел 4.1.3 .Это говорит о том, что секрет клиента не нужен, если клиент публичный, а не конфиденциальный.Также в разделе 2.1.Типы клиентов , типы конфиденциальных клиентов описываются следующим образом:

Клиенты, способные поддерживать конфиденциальность своих учетных данных (например, клиент, реализованный на защищенном сервере с ограниченным доступом к учетным данным клиента), иливозможность безопасной аутентификации клиента с использованием других средств.

Вскоре все клиенты Google, Twitter или другой крупной компании являются конфиденциальными.Поэтому при получении токена доступа необходимо использовать идентификатор клиента и секрет клиента.

Второй вопрос:

получение нового токена доступа с помощью токена обновления.

Тот же ответ с первым вопросом.Если клиент является конфиденциальным, требуется секрет клиента.

Третий вопрос:

получение ресурса по токену доступа.

Секрет клиента не являетсянеобходимо, потому что токен доступа используется сервером ресурсов.Однако секретный ключ клиента используется сервером авторизации для аутентификации клиента.Если у клиента есть токен доступа, это означает, что он уже аутентифицирован.Пожалуйста, обратитесь к раздел 7. Доступ к защищенным ресурсам .

В качестве резюме: если у вас есть токен доступа, вам не нужно требовать секрет клиента для доступа к ресурсу.Однако, если вы являетесь конфиденциальным клиентом, вы должны передать идентификатор клиента и секрет клиента на сервер авторизации (Google, Twitter и т. Д.), Чтобы получить токен доступа.

Answer 2

Вы спросили, следует ли запрашивать секрет клиента, когда клиент пытается получить ресурс по токену доступа.

Ответ

Ответ на ваш вопрос НЕТ , поскольку токен доступа представляет сам результат авторизации и предназначен для передачи через приложение , на сервер авторизации , и сервер ресурсов , в то время какСекрет клиента должен быть секретом, известным только приложению и серверу авторизации .

Я также могу сказать, что секрет клиента эквивалентен имени пользователя ииз-за этого вы не должны предоставлять его на сервер ресурсов .

Аутентификация запроса с секретом клиента для обмена временным кодом авторизации на токен доступа уменьшаетриск того, что злоумышленник перехватит код авторизации и сам его использует.

Сам токен доступа является недолговечным токен, таким образом все сниффы HTTP-доступа осуществляются с помощью токена, срок действия которого истекает .Google использует 5-минутный срок действия их API-интерфейсов OAuth 2.

Кроме того, в потоке предоставления кода авторизации токен доступа никогда не виден пользователю, снижает риск утечки токена кому-либо еще.!

~

в глубину

Давайте посмотрим на oauth 2 осадка :

3.2.1.Аутентификация клиента

Конфиденциальные клиенты или другие клиенты, выдавшие учетные данные клиента, ДОЛЖНЫ проходить проверку подлинности на сервере авторизации, как описано в разделе 2.3, при выполнении запросов к конечной точке токена.Аутентификация клиента используется для:

• Обеспечение привязки токенов обновления и кодов авторизации к клиенту, которому они были выданы.Аутентификация клиента имеет решающее значение, когда код авторизации передается в конечную точку перенаправления по небезопасному каналу или когда URI перенаправления не был зарегистрирован полностью.

• Восстановление из скомпрометированного клиента путем его отключения или изменения учетных данных, что позволяет злоумышленнику не использовать украденные токены обновления.Изменение одного набора учетных данных клиента значительно быстрее, чем отзыв всего набора маркеров обновления.

• Внедрение передовых методов управления проверкой подлинности, которые требуют периодической ротации учетных данных.Ротация всего набора токенов обновления может быть сложной, в то время как ротация одного набора учетных данных клиента значительно проще.

Клиент МОЖЕТ использовать параметр запроса "client_id", чтобы идентифицировать себя при отправке запросовк конечной точке токена.

В запросе «authorization_code» «grant_type» к конечной точке токена клиент, не прошедший проверку подлинности, ДОЛЖЕН отправить свой «client_id», чтобы не допустить непреднамеренного принятия кода, предназначенного для клиента с другим »client_id ".

Это защищает клиента от подмены кода аутентификации.(Он не обеспечивает дополнительной безопасности для защищенного ресурса.)

И раздел 2.3, дополняющий предыдущий раздел:

2.3.Аутентификация клиента

Если тип клиента является конфиденциальным, клиент и сервер авторизации устанавливают метод аутентификации клиента, подходящий для требований безопасности сервера авторизации.Сервер авторизации МОЖЕТ принять любую форму аутентификации клиента, соответствующую его требованиям безопасности.

Конфиденциальным клиентам обычно выдается (или устанавливается) набор учетных данных клиента, используемых для аутентификации на сервере авторизации (например, пароль, открытый / закрытый ключ).пара).

Сервер авторизации МОЖЕТ установить метод аутентификации клиента с общедоступными клиентами.Однако сервер авторизации НЕ ДОЛЖЕН полагаться на общедоступную аутентификацию клиента для идентификации клиента.

Клиент НЕ ДОЛЖЕН использовать более одного метода аутентификации в каждом запросе.

Инаконец, раздел 1.4, касающийся токенов доступа:

1.4.Токен доступа

Токены доступа - это учетные данные, используемые для доступа к защищенным ресурсам.Маркер доступа - это строка, представляющая авторизацию, выданную клиенту.Строка обычно непрозрачна для клиента.Токены представляют собой конкретные области действия и длительности доступа, предоставляемые владельцем ресурса и применяемые сервером ресурсов и сервером авторизации.

Токен может обозначать идентификатор, используемый для получения информации об авторизации, или самостоятельно содержать авторизациюинформация проверяемым образом (то есть строка токена, состоящая из некоторых данных и подписи).Дополнительные учетные данные аутентификации, которые выходят за рамки данной спецификации, могут потребоваться для того, чтобы клиент использовал токен.

Маркер доступа обеспечивает уровень абстракции, заменяя различные конструкции авторизации (например, имя пользователя и пароль)с одним токеном, понятным для сервера ресурсов.Эта абстракция позволяет выдавать маркеры доступа более ограниченно, чем разрешение, используемое для их получения, а также устраняет необходимость сервера ресурсов понимать широкий спектр методов аутентификации.

Токены доступа могут иметь различные форматы, структуры иметоды использования (например, криптографические свойства), основанные на требованиях безопасности сервера ресурсов.Атрибуты токена доступа и методы, используемые для доступа к защищенным ресурсам, выходят за рамки данной спецификации и определяются сопутствующими спецификациями.

Answer 3

OAuth2, использует секретный механизм клиента в качестве средства авторизации клиента и программного обеспечения, запрашивающего токен доступа.Вы можете думать о нем как о секретном пароле, который доказывает серверу аутентификации, что клиентское приложение имеет право делать запрос от имени пользователя. (на стороне сервера)

Таким образом, секрет клиента - это своего рода пароль клиента.Чтобы сервер использовал клиента, он также должен отправить свой пароль для подтверждения того, что он имеет доступ к этому клиенту.Например: приложение на стороне сервера, запрашивающее токен доступа, должно знать секрет клиента, чтобы получить токен.Это предотвращает получение вредоносными приложениями, которые не были авторизованы для использования токенов, действительного токена доступа.

Секреты клиента не используются в других типах потоков из-за чувствительной природы секретов клиента.Например, вы не будете использовать их в JavaScript или настольных приложениях, которые можно декомпилировать, исследовать, просматривать исходный код, отлаживать и т. Д. Серверы по большей части должны быть безопасными и защищенными, поэтому секрет клиента менее уязвим, чемоно находится в настольном приложении и т. д.

Сервер потока кода авторизации перешел на сторону.

• получение токена доступа из кода авторизации.
• получение новоготокен доступа с помощью маркера обновления.

Мне нравится думать о том, что если вы входите в систему с помощью веб-браузера, это клиентское приложение, мы можем доверять, чтологин - это пользователь, выполняющий это действие.

Если это серверный язык и связь осуществляется на сервере приложений, а не на компьютере пользователя, то на его серверном стороне вам потребуется отправить секрет клиента, чтобы проверить, что этот сервер действительно является правильнымсервер, у которого есть доступ к этому клиенту, и вызов не был перехвачен.

Секреты клиента по-прежнему необходимы и используются с Oauth2, это зависит только от типа используемого вами гранта и от того, является ли его серверное или клиентское приложение.

Из комментария

Я не понимаю, почему секрет клиента не нужен для получения ресурса по токену доступа

Это на самом деле отдельный вопрос, и он хороший, но я рассмотрю его здесь.

Как только приложение получит токен доступа, оно снова не проверяется.(кроме того, чтобы обеспечить его от правильного авторитета, вероятно).Ресурсы предполагают, что если токен доступа все еще действителен, то я все еще могу его использовать, поэтому нет необходимости проверять их снова.Вот почему токены доступа недолговечны и обычно действительны только в течение одного часа.Отраслевой стандарт допускает, что в случае кражи вашего токена доступа хакер имеет к нему доступ в течение очень ограниченного периода времени, поэтому может нанести небольшой ущерб.

Answer 4

Нет, вам не следует запрашивать секрет клиента, когда клиент пытается получить ресурс по токену доступа.Токена доступа должно быть достаточно, но вам нужно проверить его.