OAuth 2.0

(оригинал:учебные пособия. Кин КО v.com/OAuth2/in…)
demo: GitHub.com/Ци Хайян/Это…

Учебник по OAuth 2.0

OAuth 2.0 — это открытый стандартный протокол, который позволяет приложениям получать доступ к данным, авторизованным пользователями других приложений. Например: игра может получить информацию о пользователе в Facebook, или программа геолокации может получить информацию о пользователе в Foursquare и т. д.
Вот пример графика:

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

Варианты использования OAuth 2.0

OAuth 2.0 можно использовать не только для доступа к пользовательской информации других приложений внутри приложения, но и для предоставления служб авторизации пользователей для вызова других приложений. OAuth 2.0 является заменой OAuth 1.0, потому что OAuth 1.0 слишком сложен, например, OAuth 1.0 требует сертификатов и т. д. OAuth 2.0 проще, не требует сертификатов, использует только SSL/TLS.

Спецификация OAuth 2.0

Цель этого руководства — предоставить обзор протокола OAuth 2.0, чтобы облегчить понимание, а не охватить все детали этого протокола.
Если вы планируете внедрить протокол OAuth 2.0, лучше всего прочитать подробную спецификацию по адресу:tools.I ETF.org/HTML/draft-…

Обзор OAuth 2.0

В предыдущем введении мы упомянули, что OAuth 2.0 — это открытый стандарт, который позволяет приложениям получать доступ к данным, авторизованным пользователями других приложений. Теперь давайте представим, как работает этот протокол и различные концепции, упомянутые в спецификации.
OAuth 2.0 предоставляет различные способы получения разрешений на доступ к ресурсам на сервере ресурсов. Теперь давайте представим наиболее безопасное и наиболее распространенное их использование: как одно веб-приложение может запросить доступ к другому веб-приложению.
Следующий пример диаграммы описывает весь процесс:

Сначала пользователь заходит в клиентское приложение, в котором будет кнопка «Войти через Facebook».
На втором этапе, когда пользователь нажимает эту кнопку, он перенаправляется на сервер аутентификации (Facebook). Затем пользователь начинает авторизоваться, и после успешного входа ему будет задан вопрос, может ли клиентское приложение использовать его информацию о пользователе. Пользователь нажимает кнопку подтверждения.
На третьем этапе сервер аутентификации перенаправляет пользователя на URL-адрес, предоставленный клиентским приложением. Этот URL-адрес перенаправления обычно регистрируется на сервере аутентификации, что делает владелец клиентского приложения. После завершения регистрации сервер аутентификации сгенерирует клиент идентификатор и пароль клиента. URL-адрес перенаправления будет иметь параметр кода, который является идентификатором для этой аутентификации.
Четвертый шаг, после завершения перенаправления, пользователь попадет на перенаправленную страницу, а клиентское приложение в фоновом режиме свяжется с сервером аутентификации, отправит идентификатор клиента, пароль клиента и параметры кода, полученные на предыдущем шаге, на сервер аутентификации для аутентификации.Сервер возвращает токен доступа клиентскому приложению.
Как только клиентское приложение получит токен доступа, оно сможет использовать этот токен для доступа к связанным ресурсам, предоставляемым Facebook.

Роли приложения OAuth 2.0

OAuth 2.0 определяет следующие роли приложений:

Resource Owner （资源所有者）
Resource Server （资源服务器）
Client Application （客户端应用）
Authorization Server （认证服务器）

Resrouce Owner является владельцем данных. Например: пользователь Facebook или Google является владельцем ресурса. Ресурс, который у них есть, — это пользовательские данные. Значок пользователя на изображении в качестве примера представляет Resrouce. Владелец. Resrouce Owner также может быть приложением.

Resource Server (сервер ресурсов) — это служба, в которой хранятся ресурсы, такие как Facebook или Google — Resource Server.

Клиентское приложение запросит доступ к ресурсам, хранящимся на сервере ресурсов, которые принадлежат владельцу ресурса.

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

Тип клиента OAuth 2.0

Спецификация OAuth 2.0 определяет 2 типа клиентов:

• частный
• публичный

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

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

Представление клиентского приложения

• Веб приложение
• Пользовательский агент (богатый веб-клиент)
• Родной (родное приложение)

Веб приложение

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

Приложение User Agent (многофункциональный веб-клиент)

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

Родной (родное приложение)

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

Гибрид (гибридное приложение)

Такие приложения обычно смешивают технологии разработки нативных приложений и веб-приложений, а также имеют соответствующие внутренние серверы. Такие приложения не упоминаются в спецификации OAuth 2.0, и такие приложения могут гибко выбирать любой из трех упомянутых выше типов аутентификации.

Аутентификация OAuth 2.0

• Client ID, Client Secret and Redirect URI
• Authorization Grant
• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

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

Client ID, Client Secret and Redirect URI

Клиентское приложение необходимо зарегистрировать на сервере аутентификации.После завершения регистрации сервер аутентификации сгенерирует идентификатор клиента и пароль клиента приложения. client_id и client_password уникальны на одном и том же сервере аутентификации и не повторяются. Клиентские приложения могут быть зарегистрированы на нескольких серверах аутентификации (таких как Facebook и Google соответственно), и разные серверы аутентификации будут генерировать разные client_id и client_password для клиентских приложений.
Когда клиентское приложение необходимо получить доступ к ресурсам на сервере ресурсов, он предпочтительнее аутентификации сервером аутентификации, а соответствующий Client_id и Client_Password должен быть отправлен на сервер аутентификации во время аутентификации.
Когда клиентское приложение регистрируется на сервере аутентификации, ему необходимо заполнить URL-адрес перенаправления. После того, как владелец ресурса успешно авторизует клиентское приложение, владелец ресурса (которого можно просто понимать как пользователя системы) будет перенаправлен на страницу, указанную URL-адресом перенаправления.

проверенный

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

Спецификация OAuth 2.0 перечисляет четыре метода аутентификации и авторизации, каждый из которых имеет различные функции безопасности:

• Код авторизации (режим кода авторизации)
• Неявный (упрощенный режим)
• Учетные данные пароля владельца ресурса (режим пароля пользователя)
• Client Credentials

Каждый метод авторизации объясняется ниже.

Код авторизации (режим кода авторизации)

Процесс аутентификации кода авторизации выглядит следующим образом:

1. Владелец ресурса (пользователь) входит в клиентское приложение.
2. Клиентское приложение позволяет пользователям входить в систему через сервер аутентификации.
3. Перед входом в систему клиентское приложение перенаправит пользователя на страницу входа на сервер аутентификации и отправит идентификатор клиента на сервер аутентификации, чтобы сервер аутентификации знал, какое клиентское приложение запрашивает аутентификацию и авторизацию.
4. Пользователь входит в систему на сервере аутентификации. После успешного входа пользователю будет предложено авторизовать клиентское приложение. После того, как пользователь решит согласиться, он будет перенаправлен обратно в клиентское приложение.
5. При перенаправлении обратно в клиентское приложение используется URL-адрес перенаправления, заполненный клиентским приложением при регистрации на сервере аутентификации, и сервер аутентификации отправит код авторизации, представляющий процесс аутентификации.
6. После успешного перенаправления на клиентское приложение клиентское приложение будет взаимодействовать с сервером аутентификации в фоновом режиме и отправлять код авторизации, полученный на предыдущем шаге, вместе с идентификатором клиента и паролем клиента на сервер аутентификации.
7. Сервер аутентификации проверяет полученные данные и отправляет токен доступа клиентскому приложению после прохождения.
8. В это время клиентское приложение может использовать полученный токен доступа для перехода к серверу ресурсов для доступа к связанным ресурсам. Вот пример графика:

Неявный (упрощенный режим)

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

Учетные данные пароля владельца ресурса (режим пароля пользователя)

Учетные данные владельца ресурса (режим пароля) позволяют клиентским приложениям напрямую использовать имя пользователя и пароль пользователя. Например, пользователь может напрямую ввести имя пользователя и пароль Twitter в клиентском приложении.
Режим шифрования следует использовать только в том случае, если клиентское приложение полностью доверено. (Поскольку имя пользователя и пароль вводятся в клиентском приложении, клиентское приложение может получить и сохранить имя пользователя и пароль пользователя).
Режим шифрования обычно используется в многофункциональных клиентских веб-приложениях и собственных приложениях.

Учетные данные клиента (режим клиента)

Режим Client Credentials используется для доступа к независимым от пользователя ресурсам, поэтому авторизация пользователя не требуется.

Узел OAuth 2.0

OAuth 2.0 определяет коллекции узлов. Узел обычно представляет собой URL-адрес на веб-сервере. В частности, включают:

• Узел аутентификации
• Узел токена
• узел перенаправления

Узел аутентификации и узел Token находятся на сервере аутентификации, а узел перенаправления — на клиентском приложении. Примерная схема выглядит следующим образом:

Спецификация OAUTH 2.0 не делает четкое определение узла URL, разные реализации могут предоставлять разные URL.

Узел аутентификации

Узел аутентификации — это адрес, по которому пользователь выполняет операцию входа в систему.

Узел токена

Узел Token предоставляется сервером аутентификации, что позволяет клиентскому приложению получить адрес токена доступа.

узел перенаправления

Узел перенаправления находится в клиентском приложении, после успешной авторизации пользователя он будет перенаправлен на этот адрес.

Запросы и ответы OAuth 2.0

Когда клиентское приложение запрашивает токен доступа, отправьте HTTP-запрос на сервер аутентификации. Аутентификация и авторизация разных типов имеют разное содержание запроса и ответа. Существует четыре типа аутентификации и авторизации:

• Код авторизации (режим кода авторизации)
• Неявный (упрощенный режим)
• Учетные данные пароля владельца ресурса (режим пароля пользователя)
• Client Credentials

Содержание каждого типа запроса и ответа будет подробно объяснено в следующих разделах.

Запросы и ответы кода авторизации OAuth 2.0

Шаблон кода авторизации имеет 2 запроса и 2 ответа:

• Запрос аутентификации + ответ
• запрос токена доступа + ответ.

Запрос авторизации

Запрос на авторизацию отправляется на сервер аутентификации и получается код авторизации.

response_type   必选项，固定值为 "code"
client_id   必选项, 客户端应用在认证服务器注册时生成的client id.
redirect_uri    可选项. T客户端应用在认证服务器注册时填写的重定向URL地址.
scope   可选项. 请求的权限范围.
state   可选项 (建议提供). 客户端应用的请求URL中的参数，可以是任意值.

Ответ авторизации

Ответ авторизации содержит код авторизации, который необходимо указать при получении токена доступа позже.

code    必选项. 认证服务器返回的授权码.
state   必选项, 如果客户端应用的请求中有这个参数，既为这个参数的值.

Ответ об ошибке авторизации

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

Во-первых, клиентское приложение не проходит аутентификацию.Например, URL-адрес перенаправления, отправленный в запросе на авторизацию, не соответствует URL-адресу, который клиентское приложение заполнило при регистрации на сервере аутентификации.

Во-вторых, произошли другие ошибки, и в этом случае клиентскому приложению будет возвращена следующая информация об ошибке:

error   Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
error_description   Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
error_uri   Optional. A URI pointing to a human-readable web page with information about the error.
state   Required, if present in authorization request. The same value as sent in the state parameter in the request.

Запрос токена

После того как клиентское приложение получит код авторизации, оно может использовать код авторизации для получения токена доступа. Параметры запроса следующие:

client_id   Required. The client application's id.
client_secret   Required. The client application's client secret .
grant_type  Required. Must be set to authorization_code .
code    Required. The authorization code received by the authorization server.
redirect_uri    Required, if the request URI was included in the authorization request. Must be identical then.

Токен ответ

Содержимое ответа токена доступа находится в формате json:

{ "access_token"  : "...",
  "token_type"    : "...",
  "expires_in"    : "...",
  "refresh_token" : "...",
}

access_token : токен доступа,
token_type : тип токена, обычно носитель,
expires_in : время истечения срока действия токена в секундах,
refresh_token : когда срок действия токена доступа истечет, вы можете использовать токен обновления, чтобы получить новый токен доступа.

Запросы и ответы упрощенного режима OAuth 2.0

Упрощенный режим имеет только один запрос и один ответ.

Упрощенный запрос авторизации схемы

Параметры этого запроса следующие:

response_type   Required. Must be set to token .
client_id   Required. The client identifier as assigned by the authorization server, when the client was registered.
redirect_uri    Optional. The redirect URI registered by the client.
scope   Optional. The possible scope of the request.
state   Optional (recommended). Any client state that needs to be passed on to the client request URI.

Упрощенная модель авторизации

Ответ содержит следующие параметры, обратите внимание, что формат ответа не json.

access_token    Required. The access token assigned by the authorization server.
token_type  Required. The type of the token
expires_in  Recommended. A number of seconds after which the access token expires.
scope   Optional. The scope of the access token.
state   Required, if present in the autorization request. Must be same value as state parameter in request.

Упрощенный модальный ответ на ошибку

Есть две ситуации, которые могут вызвать ошибки: во-первых, клиентское приложение не может пройти аутентификацию, например, URL-адрес перенаправления, отправленный в запросе авторизации, не соответствует URL-адресу, заполненному клиентским приложением при регистрации на сервере аутентификации.

Во-вторых, произошли другие ошибки, и в этом случае клиентскому приложению будет возвращена следующая информация об ошибке:

error   Required. Must be one of a set of predefined error codes. See the specification for the codes and their meaning.
error_description   Optional. A human-readable UTF-8 encoded text describing the error. Intended for a developer, not an end user.
error_uri   Optional. A URI pointing to a human-readable web page with information about the error.
state   Required, if present in authorization request. The same value as sent in the state parameter in the request.

Запросы и ответы в режиме пароля пользователя

Режим пароля пользователя имеет только один запрос и ответ.

Запрос режима пароля пользователя

Запрос содержит следующие параметры:

grant_type  必选项. 固定值 "password"
username    必选项. UTF-8编码的用户名.
password    必选项. UTF-8编码的密码.
scope   可选项. 请求的权限范围.

Ответ в режиме пароля пользователя

Содержимое ответа в формате json:

{ "access_token"  : "...",
  "token_type"    : "...",
  "expires_in"    : "...",
  "refresh_token" : "...",
}

access_token : токен доступа,
token_type : тип токена,
expires_in : время истечения срока действия токена в секундах,
refresh_token : когда срок действия токена доступа истечет, вы можете использовать токен обновления, чтобы получить новый токен доступа.

Запросы и ответы в клиентском режиме

запрос режима клиента

Запрос содержит следующие параметры:

grant_type  必选项. 固定值 "client_credentials". 
scope   可选项. 请求的权限范围.

Ответ в режиме клиента

Ответ содержит следующие параметры:

{ "access_token"  : "...",
  "token_type"    : "...",
  "expires_in"    : "...",
}

access_token : токен доступа,
token_type : тип токена,
expires_in : время истечения срока действия токена в секундах,
Обратите внимание, что для этого типа авторизации нет refresh_token.