OAuth 2.0 — Обзор

OAuth — это открытый протокол авторизации, который позволяет получить доступ к ресурсам владельца ресурса путем включения клиентских приложений на HTTP-сервисах, таких как Facebook, GitHub и т. Д. Он позволяет обмениваться ресурсами, хранящимися на одном сайте, с другим сайтом без использования их учетных данных. Вместо этого используются токены имени пользователя и пароля.

OAuth 2.0 разработан рабочей группой IETF OAuth , опубликованной в октябре 2012 года.

Зачем использовать OAuth 2.0?

• Вы можете использовать OAuth 2.0 для чтения данных пользователя из другого приложения.

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

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

Вы можете использовать OAuth 2.0 для чтения данных пользователя из другого приложения.

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

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

Особенности OAuth 2.0

• OAuth 2.0 — это простой протокол, который позволяет получить доступ к ресурсам пользователя без совместного использования паролей.

• Он предоставляет потоки пользовательских агентов для запуска клиентского приложения с использованием языка сценариев, такого как JavaScript. Как правило, браузер — это пользовательский агент.

• Он получает доступ к данным с помощью токенов вместо использования их учетных данных и сохраняет данные в онлайн-файловой системе пользователя, такой как Google Docs или аккаунт Dropbox.

OAuth 2.0 — это простой протокол, который позволяет получить доступ к ресурсам пользователя без совместного использования паролей.

Он предоставляет потоки пользовательских агентов для запуска клиентского приложения с использованием языка сценариев, такого как JavaScript. Как правило, браузер — это пользовательский агент.

Он получает доступ к данным с помощью токенов вместо использования их учетных данных и сохраняет данные в онлайн-файловой системе пользователя, такой как Google Docs или аккаунт Dropbox.

Преимущества OAuth 2.0

• OAuth 2.0 — очень гибкий протокол, использующий SSL (Secure Sockets Layer, который обеспечивает конфиденциальность данных между веб-сервером и браузерами) для сохранения токена доступа пользователя.

• OAuth 2.0 использует SSL, который используется для обеспечения протоколов криптографической индустрии и используется для обеспечения безопасности данных.

• Это разрешает ограниченный доступ к данным пользователя и позволяет получить доступ по истечении срока действия токенов авторизации.

• Он имеет возможность обмениваться данными для пользователей без необходимости разглашения личной информации.

• Это проще в реализации и обеспечивает более строгую аутентификацию.

OAuth 2.0 — очень гибкий протокол, использующий SSL (Secure Sockets Layer, который обеспечивает конфиденциальность данных между веб-сервером и браузерами) для сохранения токена доступа пользователя.

OAuth 2.0 использует SSL, который используется для обеспечения протоколов криптографической индустрии и используется для обеспечения безопасности данных.

Это разрешает ограниченный доступ к данным пользователя и позволяет получить доступ по истечении срока действия токенов авторизации.

Он имеет возможность обмениваться данными для пользователей без необходимости разглашения личной информации.

Это проще в реализации и обеспечивает более строгую аутентификацию.

Недостатки OAuth 2.0

• Если вы добавите дополнительное расширение в конце спецификации, оно создаст широкий спектр не совместимых реализаций, что означает, что вам придется писать отдельные фрагменты кода для Facebook, Google и т. Д.

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

Если вы добавите дополнительное расширение в конце спецификации, оно создаст широкий спектр не совместимых реализаций, что означает, что вам придется писать отдельные фрагменты кода для Facebook, Google и т. Д.

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

OAuth 2.0 — Архитектура

В этой главе мы обсудим архитектурный стиль OAuth 2.0.

Шаг 1. Сначала пользователь получает доступ к ресурсам с помощью клиентского приложения, такого как Google, Facebook, Twitter и т. Д.

Шаг 2 — Далее клиентскому приложению будет предоставлен идентификатор клиента и пароль клиента во время регистрации URI перенаправления (универсального идентификатора ресурса).

Шаг 3 — Пользователь входит в систему, используя приложение для аутентификации. Идентификатор клиента и пароль клиента являются уникальными для клиентского приложения на сервере авторизации.

Шаг 4 — Сервер аутентификации перенаправляет пользователя на универсальный идентификатор ресурса (URI) перенаправления с использованием кода авторизации.

Шаг 5 — Пользователь получает доступ к странице, расположенной по адресу URI перенаправления в клиентском приложении.

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

Шаг 7 — Приложение аутентификации возвращает токен доступа клиентскому приложению.

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

OAuth 2.0 имеет различные концепции, которые кратко описаны в следующей таблице.

Sr.No.	Концепция и описание
1	терминология OAuth предлагает несколько дополнительных терминов для понимания концепции авторизации.
2	Веб сервер Веб-сервер доставляет веб-страницы и использует HTTP для предоставления пользователям файлов, которые формируют веб-страницы.
3	User-Agent Приложение агента пользователя используется клиентскими приложениями на устройстве пользователя, которое выступает в качестве экземпляра языка сценариев.
4	Родное приложение Собственное приложение можно использовать в качестве экземпляра приложения для настольного компьютера или мобильного телефона, в котором используются учетные данные владельца ресурса.

OAuth предлагает несколько дополнительных терминов для понимания концепции авторизации.

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

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

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

OAuth 2.0 — учетные данные клиента

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

• Клиент запрашивает токен доступа только с помощью учетных данных клиента.

• Поток авторизации учетных данных клиента используется для получения токена доступа для авторизации запросов API.

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

Клиент запрашивает токен доступа только с помощью учетных данных клиента.

Поток авторизации учетных данных клиента используется для получения токена доступа для авторизации запросов API.

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

На следующем рисунке показан поток учетных данных клиента.

Поток, показанный на рисунке выше, состоит из следующих этапов:

Шаг 1 — Клиент аутентифицируется на сервере авторизации и делает запрос на токен доступа от конечной точки токена.

Шаг 2 — Сервер авторизации аутентифицирует клиента и предоставляет токен доступа, если он действителен и авторизован.

В следующей таблице перечислены понятия учетных данных клиента.

Sr.No.	Концепция и описание
1	Получение авторизации для конечного пользователя Конечной точкой авторизации обычно является URI на сервере авторизации, на котором владелец ресурса входит в систему и разрешает доступ к данным клиентскому приложению.
2	Ответ авторизации Ответ авторизации может использоваться для получения токена доступа для доступа к ресурсам владельца в системе с использованием кода авторизации.
3	Ответ об ошибках и коды Сервер авторизации отвечает с помощью кодов состояния HTTP 400 или 401 (неверный запрос), если во время авторизации произошла ошибка.

Конечной точкой авторизации обычно является URI на сервере авторизации, на котором владелец ресурса входит в систему и разрешает доступ к данным клиентскому приложению.

Ответ авторизации может использоваться для получения токена доступа для доступа к ресурсам владельца в системе с использованием кода авторизации.

Сервер авторизации отвечает с помощью кодов состояния HTTP 400 или 401 (неверный запрос), если во время авторизации произошла ошибка.

OAuth 2.0 — получение токена доступа

Маркер доступа — это строка, которая идентифицирует пользователя, приложение или страницу. Токен содержит информацию о том, когда истекает срок действия токена и какое приложение создало этот токен.

• Во-первых, необходимо получить учетные данные клиента OAuth 2.0 из консоли API.

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

• Он получает токен доступа из ответа и отправляет токен API, к которому вы хотите получить доступ.

Во-первых, необходимо получить учетные данные клиента OAuth 2.0 из консоли API.

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

Он получает токен доступа из ответа и отправляет токен API, к которому вы хотите получить доступ.

Вы должны отправить пользователя в конечную точку авторизации в начале. Ниже приведен пример фиктивного запроса

https://publicapi.example.com/oauth2/authorize?client_id=your_client_id&redirect_uri=your_url 
   &response_type=code

Ниже приведены параметры и их описания.

• client_id — должен быть установлен на идентификатор клиента вашего приложения.

• redirect_uri — должен быть установлен на URL. После авторизации запроса пользователь будет перенаправлен обратно.

• response_type — это может быть либо код, либо токен. Код должен использоваться для приложений на стороне сервера, тогда как токен должен использоваться для приложений на стороне клиента. В серверных приложениях вы можете быть уверены, что секреты сохранены безопасно.

client_id — должен быть установлен на идентификатор клиента вашего приложения.

redirect_uri — должен быть установлен на URL. После авторизации запроса пользователь будет перенаправлен обратно.

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

В следующей таблице перечислены понятия учетных данных клиента.

Sr.No.	Концепция и описание
1	Код авторизации Код авторизации позволяет получить доступ к запросу авторизации и предоставляет доступ клиентскому приложению для извлечения ресурсов владельца.
2	Учетные данные пароля владельца ресурса Учетные данные пароля владельца ресурса включают только один запрос и один ответ и полезны, когда владелец ресурса имеет хорошие отношения с клиентом.
3	Утверждение Утверждение — это пакет информации, который делает возможным обмен информацией о личности и безопасности между различными доменами безопасности.
4	Обновить токен Токены обновления используются для получения новых токенов доступа, которые содержат информацию, необходимую для получения нового токена доступа.
5	Ответ токена доступа Токен доступа — это тип токена, который назначается сервером авторизации.
6	Коды ответа об ошибках доступа к токену Если запрос доступа к токену, выданный сервером авторизации, недействителен или не авторизован, сервер авторизации возвращает ответ об ошибке.

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

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

Утверждение — это пакет информации, который делает возможным обмен информацией о личности и безопасности между различными доменами безопасности.

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

Токен доступа — это тип токена, который назначается сервером авторизации.

Если запрос доступа к токену, выданный сервером авторизации, недействителен или не авторизован, сервер авторизации возвращает ответ об ошибке.

OAuth 2.0 — доступ к защищенному ресурсу

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

Существует два стандартных способа отправки учетных данных:

• Токен на предъявителя — токен доступа может быть размещен только в теле запроса POST или в параметре GET URL как запасной вариант в HTTP-заголовке авторизации.

Токен на предъявителя — токен доступа может быть размещен только в теле запроса POST или в параметре GET URL как запасной вариант в HTTP-заголовке авторизации.

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

Authorization: Bearer [token-value]

Например —

GET/resource/1 HTTP /1.1
Host: example.com
Authorization: Bearer abc...

• MAC — Криптографический код аутентификации сообщения (MAC) вычисляется с использованием элементов запроса и отправляется в заголовок авторизации. После получения запроса MAC сравнивается и вычисляется владельцем ресурса.

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

В следующей таблице приведены концепции доступа к защищенному ресурсу.

Sr.No.	Концепция и описание
1	Аутентифицированные Запросы Он используется для получения токена кода авторизации для доступа к ресурсам владельца в системе.
2	Поле заголовка ответа WWW-Authenticate Сервер ресурсов включает поле заголовка ответа «WWW-Authenticate», если запрос защищенного ресурса содержит недопустимый токен доступа.

Он используется для получения токена кода авторизации для доступа к ресурсам владельца в системе.

Сервер ресурсов включает поле заголовка ответа «WWW-Authenticate», если запрос защищенного ресурса содержит недопустимый токен доступа.

OAuth 2.0 — расширяемость

Существует два способа определения типов токенов доступа:

• Зарегистрировавшись в реестре типа токена доступа.

• Используя в качестве имени уникальный абсолютный URI (Uniform Resource Identifier).

Зарегистрировавшись в реестре типа токена доступа.

Используя в качестве имени уникальный абсолютный URI (Uniform Resource Identifier).

Определение новых параметров конечной точки

Имена параметров должны соответствовать имени параметра ABNF (расширенная форма Бэкуса-Наура — это метаязык, основанный на форме Бэкуса-Наура, состоящей из собственного синтаксиса и правил деривации), а синтаксис значений параметров должен быть четко определен.

param-name = 1* name-char
name-char = "-" / "." / "_" / DIGIT / ALPHA

Определение новых типов грантов авторизации

Новым типам предоставления полномочий может быть назначен отдельный абсолютный URI для использования с помощью параметра «grant_type». Тип предоставления расширения должен быть зарегистрирован в реестре параметров OAuth, если для этого требуются дополнительные параметры конечной точки токена.

Определение новых типов ответов конечной точки авторизации

response-type = response-name *(SP response-name)
response-name = 1* response-char
response-char = "_" / DIGIT / ALPHA

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

Определение дополнительных кодов ошибок

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

error = 1 * error_char
error-char =  %x20-21 / %x23-5B / 5D-7E

OAuth 2.0 — Соображения IANA

IANA расшифровывается как «сеть Интернет-подписчиков», которая предоставляет информацию о регистрационных значениях, связанных с аутентификацией R- EMote, а также услугой RADIUS.

IANA включает в себя следующие соображения —

Реестр типов токенов доступа OAuth

Токены доступа OAuth зарегистрированы экспертами с необходимой спецификацией. Если они удовлетворены регистрацией, только тогда они опубликуют спецификацию. Запрос на регистрацию будет отправлен на @ ietf.org для проверки по теме («Запрос на тип токена доступа: пример»). Эксперты отклонят или примут запрос в течение 14 дней с момента запроса.

Шаблон регистрации

Шаблон регистрации содержит следующие спецификации —

• Имя типа — это имя запроса.

• Параметры ответа конечной точки токена — Дополнительный параметр ответа токена доступа будет зарегистрирован отдельно в реестре параметров OAuth.

• Схема аутентификации HTTP — Схема аутентификации HTTP может использоваться для аутентификации ресурсов с использованием токена доступа.

• Change Controller — Дайте название штата как «IETF» для стандартных RFC дорожек, а для других используйте имя ответственной стороны.

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

Имя типа — это имя запроса.

Параметры ответа конечной точки токена — Дополнительный параметр ответа токена доступа будет зарегистрирован отдельно в реестре параметров OAuth.

Схема аутентификации HTTP — Схема аутентификации HTTP может использоваться для аутентификации ресурсов с использованием токена доступа.

Change Controller — Дайте название штата как «IETF» для стандартных RFC дорожек, а для других используйте имя ответственной стороны.

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

Реестр параметров OAuth

Реестр параметров OAuth содержит регистрацию запроса или ответа конечной точки авторизации, запроса конечной точки токена или ответа экспертов с требуемой спецификацией. Запрос на регистрацию будет отправлен экспертам, и если они удовлетворены регистрацией, они опубликуют спецификацию.

Шаблон регистрации

Шаблон регистрации содержит спецификации, такие как имя типа, контроллер изменений и документ спецификации, как определено в приведенном выше разделе « Реестр типов токенов доступа OAuth », за исключением следующей спецификации:

Расположение использования параметра — указывает местоположение параметра, такого как запрос авторизации или ответ, запрос токена или ответ.

Начальное содержимое реестра

В следующей таблице показан реестр параметров OAuth, содержащий начальное содержимое.

Sr.No.	Имя параметра и местоположение использования	Изменить контроллер	Технический документ
1	ID клиента запрос авторизации, запрос токена	IETF	RFC 6749
2	client_secret запрос токена	IETF	RFC 6749
3	response_type authorization_request	IETF	RFC 6749
4	redirect_uri запрос авторизации, авторизация	IETF	RFC 6749
5	объем запрос авторизации или ответ, запрос токена или ответ	IETF	RFC 6749
6	государство запрос авторизации или ответ	IETF	RFC 6749
7	код запрос токена, ответ авторизации	IETF	RFC 6749
8	error_description ответ авторизации, ответ токена	IETF	RFC 6749
9	error_uri ответ авторизации, ответ токена	IETF	RFC 6749
10	grant_type запрос токена	IETF	RFC 6749
11	access_token ответ авторизации, ответ токена	IETF	RFC 6749
12	token_type ответ авторизации, ответ токена	IETF	RFC 6749
13	истекает ответ авторизации, ответ токена	IETF	RFC 6749
14	имя пользователя запрос токена	IETF	RFC 6749
15	пароль запрос токена	IETF	RFC 6749
16	refresh_token запрос токена, ответ токена	IETF	RFC 6749

ID клиента

запрос авторизации, запрос токена

client_secret

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

response_type

authorization_request

redirect_uri

запрос авторизации, авторизация

объем

запрос авторизации или ответ, запрос токена или ответ

государство

запрос авторизации или ответ

код

запрос токена, ответ авторизации

error_description

ответ авторизации, ответ токена

error_uri

ответ авторизации, ответ токена

grant_type

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

access_token

ответ авторизации, ответ токена

token_type

ответ авторизации, ответ токена

истекает

ответ авторизации, ответ токена

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

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

пароль

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

refresh_token

запрос токена, ответ токена

Реестр типов ответов конечной точки авторизации OAuth

Это можно использовать для определения реестра типов ответов конечной точки авторизации OAuth. Типы ответов регистрируются экспертами с требуемой спецификацией, и если они удовлетворены регистрацией, только тогда они опубликуют спецификацию. Запрос на регистрацию будет отправлен на @ ietf.org для ознакомления. Эксперты отклонят или примут запрос в течение 14 дней с момента запроса.

Шаблон регистрации

Шаблон регистрации содержит спецификации, такие как имя типа, контроллер изменений и документ спецификации, как определено в приведенном выше разделе « Реестр типов токенов доступа OAuth ».

Начальное содержимое реестра

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

Sr.No.	Имя параметра	Изменить контроллер	Технический документ
1	код	IETF	RFC 6749
2	знак	IETF	RFC 6749

Реестр ошибок OAuth

Это можно использовать для определения реестра ошибок OAuth Extensions. Коды ошибок вместе с расширениями протокола, такими как типы предоставления, типы токенов и т. Д., Регистрируются экспертами с необходимой спецификацией. Если они удовлетворены регистрацией, то они опубликуют спецификацию. Запрос на регистрацию будет отправлен на @ ietf.org для ознакомления с темой («Запрос кода ошибки: пример»). Эксперты отклонят или примут запрос в течение 14 дней с момента запроса.

Шаблон регистрации

Шаблон регистрации содержит спецификации, такие как контроллер изменений и документ спецификации, как определено в приведенном выше разделе « Реестр типов маркеров доступа OAuth », за исключением следующих спецификаций:

Имя ошибки — это имя запроса.

Местоположение использования ошибки — указывает местоположение ошибки, например, ответ об ошибке предоставления кода авторизации, ответ неявного предоставления или ответа об ошибке токена и т. Д., Где указывается, где можно использовать ошибку.

Связанное расширение протокола — Вы можете использовать расширения протокола, такие как тип предоставления расширения, тип токена доступа, параметр расширения и т. Д.