предисловие
Возьмем простой пример. Sina Weibo — это ваш дом, и иногда вы хотите попросить некоторых людей (сторонние приложения) пойти к вам домой, чтобы помочь вам что-то сделать или получить что-то. Вы можете напрямую скопировать им ключ (имя пользователя и пароль), но здесь есть несколько проблем:
- Другие могут пройти во все комнаты в вашем доме после того, как получат ключи.
- После того, как кто-то получит ваш ключ, он может случайно потерять его или даже нарочно отдать кому-то другому. Таким образом, вы даже не знаете, у кого есть ключи от вашего дома.
- Через некоторое время вы можете захотеть вернуть свои ключи, но что, если другие этого не сделают?
Подводя итог, есть две проблемы: во-первых, человек, получивший ключ, имеет слишком много полномочий и может войти в любую комнату; во-вторых, человек, получивший ключ, может скопировать и изменить ключ.
OAuth — это расширенный ключ, который можно понимать как распознавание отпечатков пальцев, он в основном устраняет перечисленные выше дефекты:
- Вы можете настроить ключи с различными разрешениями. Некоторые могут войти только в лобби (почитайте вашу ленту Weibo). Некоторые ключи могут быть помещены в шкафчики для хранения (читайте ваше фото).
- В ключе есть программа проверки отпечатка пальца (fingerprint=appkey), и пользоваться ключом может только тот, кто получил ключ.
- Ключ имеет определенную актуальность, а так же аннулировать ключ можно дистанционно.
текст
OAuthоколоРазрешить(authorization) — открытый сетевой стандарт, который широко используется во всем мире.2.0Версия.
Эта статья оOAuth 2.0Идеи дизайна и процесс работы делают краткое и популярное объяснение.
Сценарии применения
чтобы понятьOAuthПрименимый сценарий , приведите простой для понимания пример.
Существует веб-сайт «облачной печати», который может распечатывать фотографии пользователей, хранящиеся в Google. Чтобы использовать эту услугу, пользователи должны разрешить «облачной печати» читать свои фотографии, хранящиеся в Google.
Проблема в том, что Google разрешает «облачной печати» читать эти фотографии только с разрешения пользователя. Тогда как «Облачная печать» получает авторизацию пользователей? Традиционный метод заключается в том, что пользователи сообщают «облачной печати» свое имя пользователя и пароль Google, и последний может прочитать фотографию пользователя. Этот подход имеет следующие серьезные недостатки.
1. "云冲印"为了后续的服务，会保存用户的密码，这样很不安全。
2. Google不得不部署密码登录，而我们知道，单纯的密码登录并不安全。
3. "云冲印"拥有了获取用户储存在Google所有资料的权利，用户没法限制"云冲印"获得授权的范围和有效期。
4. 用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。
5. 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。
OAuth был создан для решения этих проблем.
Терминология
объяснить подробноOAuth 2.0Перед этим вам нужно понять несколько конкретных терминов. Они имеют решающее значение для чтения последующих объяснений, особенно изображений.
| Терминология | Китайское значение | конкретное объяснение |
|---|---|---|
| Third-party application | сторонние приложения | Эта статья также называется «клиент» (клиент), что является «облачной печатью» в примере из предыдущего раздела. |
| Resource Owner | владелец ресурса | Эта статья также упоминается как «пользователь» (user). |
| HTTP service | Поставщик услуг HTTP | Эта статья упоминается как «поставщик услуг», то есть Google в примере из предыдущего раздела. |
| User Agent | пользовательский агент | Эта статья относится к браузеру. |
| Authorization server | Сервер аутентификации | Сервер, который поставщик услуг использует исключительно для обработки аутентификации. |
| Resource server | сервер ресурсов | То есть сервер, на котором поставщик услуг размещает созданные пользователями ресурсы. Он и сервер аутентификации могут быть одним сервером или другим сервером. |
Идея OAuth
OAuthсуществует"клиент"и"поставщик услуг"Между, установитьуровень авторизации(authorization layer). "клиент"Не удается войти напрямую"поставщик услуг", только авторизоватьсяуровень авторизации, что отличает пользователей от клиентов. "клиент"Авторизоватьсяуровень авторизациииспользовалжетон(token), который отличается от пароля пользователя. Пользователь может указать область разрешений и срок действия токена уровня авторизации при входе в систему.
После того, как «клиент» войдет на уровень авторизации, «поставщик услуг» в соответствии с токеномСфера полномочийиСрок годности,В направлении"клиент"Открыть сохраненные пользователем данные.
конкретный процесс
(A). 用户打开客户端以后，客户端要求用户给予授权。
(B). 用户同意给予客户端授权。
(C). 客户端拿到上一步获取到的授权，向认证服务器申请令牌。
(D). 认证服务器对客户端进行认证以后，确认无误，统一发放令牌。
(E). 客户端使用令牌，向资源服务器申请获取用户的资源。
(F). 资源服务器确认令牌无误，同意向客户端开放资源。
Нетрудно заметить, что вышеизложенноешесть шаговсреди шагов(B)Это ключ, то есть то, как пользователь может авторизовать клиента. с этимРазрешитьПозже клиент может получитьжетон, а затем пожетонПолучатьресурс.
Несколько режимов авторизации
Клиент должен получитьРазрешить. (authorization grant) чтобы получитьжетон(access token).OAuth 2.0Определены четыре метода авторизации.
- Код авторизации
- Упрощенный режим (неявный)
- Режим пароля (учетные данные пароля владельца ресурса)
- Режим клиента (учетные данные клиента)
Далее объясняется приобретение клиентов по одномуРазрешитьизЧетыре режима.
(1) Режим кода авторизации
Режим кода авторизации(authorization code)ДаСамая полная функция,Самый строгий процессизРежим авторизации. Он характеризуетсяклиентизвнутренний сервер,и"поставщик услуг"изСервер аутентификациивзаимодействовать.
Его шаги следующие:
(A). 用户访问客户端，后者将前者导向认证服务器。
(B). 用户选择是否给予客户端授权。
(C). 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"(redirection URI)，同时附上一个授权码。
(D). 客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。
(E). 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌(access token)和更新令牌(refresh token)。
Конкретные параметры, необходимые для каждого шага, следующие:
На шаге A URI для клиента, который будет применяться для проверки подлинности, включает следующие параметры:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| response_type | Тип авторизации | Обязательный, значение здесь фиксируется как «код». |
| client_id | идентификатор клиента | обязательный |
| redirect_uri | URI перенаправления | по желанию |
| scope | Область применения | по желанию |
| state | Текущее состояние клиента, сервер аутентификации вернет это значение без изменений | Необязательно, вы можете указать любое значение |
Ниже приведен пример:
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
На шаге C сервер отвечает на URI клиента со следующими параметрами:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| code | Код авторизации. Срок действия кода должен быть очень коротким, обычно устанавливается на 10 минут, и клиент может использовать код только один раз, иначе он будет отклонен сервером авторизации. Существует однозначное соответствие между этим кодом и идентификатором клиента и URI перенаправления. | обязательный |
| state | Если запрос клиента включает этот параметр, ответ сервера аутентификации ДОЛЖЕН также включать этот параметр. | по желанию |
Ниже приведен пример:
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
На шаге D клиент делает HTTP-запрос токена с сервера аутентификации, включая следующие параметры:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| grant_type | Режим авторизации | Обязательное, значение здесь фиксировано как "authorization_code" |
| code | Код авторизации, полученный на предыдущем шаге | обязательный |
| redirect_uri | URI перенаправления | Требуется и должно соответствовать значению параметра на шаге A |
| client_id | ID клиента | обязательный |
Ниже приведен пример:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
На шаге E ответ HTTP, отправленный сервером аутентификации, содержит следующие параметры:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| access_token | токен доступа | обязательный |
| token_type | Тип карты, значение не чувствительно к регистру | Обязательный, может быть типа носителя или типа Mac |
| expires_in | Срок действия, в секундах. Если этот параметр опущен, время истечения нужно задавать другими способами | по желанию |
| refresh_token | Обновите токен, чтобы получить следующий токен доступа | по желанию |
| scope | Область применения | по желанию |
Ниже приведен пример:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Как видно из приведенного выше кода, соответствующие параметры используютJSONформат отправки(Content-Type: application/json). также,HTTPявно указано в заголовкене должен кэшироваться.
(2) Упрощенный режим
упрощенный режим(implicit grant type)Потерпеть поражениетретья сторонасервер приложений, непосредственно вбраузерСерединаСервер аутентификацииПрименятьжетон, пропущено"Код авторизации«Этот шаг, отсюда и название. Все шаги выполняются в браузере, токен виден посетителю, и клиент не требует аутентификации.
Его шаги следующие:
(A). 客户端将用户导向认证服务器。
(B). 用户决定是否给于客户端授权。
(C). 假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。
(D). 浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。
(E). 资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
(F). 浏览器执行上一步获得的脚本，提取出令牌。
(G). 浏览器将令牌发给客户端。
Вот параметры, необходимые для вышеуказанных шагов:
На шаге A HTTP-запрос, отправленный клиентом, содержит следующие параметры:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| response_type | Тип авторизации | Обязательный, значение здесь фиксировано как «токен». |
| client_id | идентификатор клиента | обязательный |
| redirect_uri | URI перенаправления | по желанию |
| scope | Область применения | по желанию |
| state | Текущее состояние клиента, сервер аутентификации вернет это значение без изменений | Необязательно, вы можете указать любое значение |
Ниже приведен пример:
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
На шаге C сервер аутентификации отвечает на URI клиента со следующими параметрами:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| access_token | токен доступа | обязательный |
| token_type | Тип карты, значение не чувствительно к регистру | обязательный |
| expires_in | Срок действия, в секундах. Если этот параметр опущен, время истечения нужно задавать другими способами | по желанию |
| scope | Сфера полномочий | Если это соответствует области применения клиентского приложения, этот пункт можно опустить. |
| state | Если запрос клиента содержит этот параметр, ответ сервера аутентификации также должен содержать тот же параметр. | по желанию |
Ниже приведен пример:
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
Ниже приведен пример:
HTTP/1.1 302 Found
Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=bearer&expires_in=3600
В приведенном выше примере сервер аутентификации используетHTTPинформация заголовкаLocationстолбец, указатьперенаправление браузераURL-адрес . Обратите внимание, что по этому URLHashчасть содержитжетон.
Согласно вышеизложенномуDШаг, следующий шаг, который посетит браузерLocationуказанный URL, ноHashЗапчасти не отправляются.
СледующееEшаги, поставщик услугсервер ресурсовприслаликод скрипта, будет извлекатьHashсерединажетон.
(3) Режим пароля
режим пароля(Resource Owner Password Credentials Grant), пользователь предоставляет клиенту своюимя пользователяипароль. Клиент использует эту информацию для "поставщик услуг"проситьРазрешить.
В этом режиме пользователь должен поставить свой собственныйпарольклиенту, ноКлиенты не должны хранить пароли. Это обычно используется вПользовательправильноКлиенты пользуются большим доверием, например, клиент является частью операционной системы или производится известной компанией. Сервер аутентификации должен использовать этот режим только в том случае, если другие режимы авторизации не могут быть реализованы.
Его шаги следующие:
(A). 用户向客户端提供用户名和密码。
(B). 客户端将用户名和密码发给认证服务器，向后者请求令牌。
(C). 认证服务器确认无误后，向客户端提供访问令牌。
На шаге B HTTP-запрос, отправленный клиентом, содержит следующие параметры:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| grant_type | Тип авторизации | Обязательно, значение здесь фиксировано на «пароль» |
| username | имя пользователя | обязательный |
| password | пароль пользователя | обязательный |
| scope | Область применения | по желанию |
Ниже приведен пример:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w
На шаге C сервер аутентификации отправляет токен доступа клиенту:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| access_token | токен доступа | обязательный |
| token_type | Тип карты, значение не чувствительно к регистру | обязательный |
| expires_in | Срок действия, в секундах. Если этот параметр опущен, время истечения нужно задавать другими способами | по желанию |
| scope | Сфера полномочий | Если это соответствует области применения клиентского приложения, этот пункт можно опустить. |
| example_parameter | Если запрос клиента содержит этот параметр, ответ сервера аутентификации также должен содержать тот же параметр. | по желанию |
Ниже приведен пример:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
(4) Режим клиента
клиентский режим(Client Credentials Grant)Ссылаться наклиентна свое имя, а не наПользовательв честь "поставщик услуг«Для аутентификации. Строго говоря, режим клиента не является частью проблемы, для решения которой разработана структура OAuth.
В этом режимеПользовательпрямо кРегистрация клиента,клиенттребовать от своего имени"поставщик услуг«При оказании услуг фактически нет вопроса авторизации.
Его шаги следующие:
(A). 客户端向认证服务器进行身份认证，并要求一个访问令牌。
(B). 认证服务器确认无误后，向客户端提供访问令牌。
На шаге A HTTP-запрос, отправленный клиентом, содержит следующие параметры:
| параметр | конкретное значение | Требуется ли |
|---|---|---|
| grant_type | Тип авторизации | Обязательный, значение здесь фиксируется как «clientcredentials». |
| scope | Сфера полномочий | по желанию. |
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
Сервер аутентификации должен каким-то образом проверить личность клиента.
На шаге B сервер аутентификации отправляет токен доступа клиенту.Вот пример:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"example_parameter":"example_value"
}
Суммировать
В этой статье описываетсяOAuth 2.0Некоторые основные понятия и четыре режима авторизации: режим кода авторизации, простой режим, режим пароля и режим клиента. о
Добро пожаловать в технический публичный аккаунт: Zero One Technology Stack
Эта учетная запись будет продолжать делиться сухими товарами серверных технологий, включая основы виртуальных машин, многопоточное программирование, высокопроизводительные фреймворки, асинхронное ПО, промежуточное ПО для кэширования и обмена сообщениями, распределенные и микросервисы, материалы для обучения архитектуре и расширенные учебные материалы и статьи. ## ##