Oauth: OAuth 2.0 простым и понятным языком / Хабр

Перевыпуск с использованием схемы Authorization Basic

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

Запрос имеет вид:

POST https://api.nic.ru/oauth/token HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

В HTTP-заголовке Authorization передается строка <client_id>:<client_secret>, закодированная методом base64. Здесь <client_id> — идентификатор приложения, <client_secret> — пароль приложения (оба атрибута генерируются после регистрации приложения).

Параметр grant_type=refresh_token, а параметр refresh_token должен содержать значениe токена перевыпуска (например: refresh_token=tGzv3JOkF0XG5Qx2TlKWIA).

Перевыпуск в случае явной передачи идентификатора и пароля

Альтернативный вариант, вместо заголовка Authorization используется передача параметров client_id и client_secret:

POST https://api.nic.ru/oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id =app12312312&client_secret=password

Формат ответа в случае успеха

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",
}

Формат ответа в случае ошибки

HTTP/1. 1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
   "error":"invalid_request"
}

HTTP-код ответа может быть 400, 401. В теле ответа помимо error могут быть дополнительные параметры, например:

invalid_request — неверный формат запроса;
invalid_grant — неверный или просроченный код подтверждения;
unsupported_grant_type — неверное значение параметра grant_type.

Как работает OAuth 2.0 и OpenID Connect

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

В этой статье рассмотрим историю возникновения и схему работы. Разберемся в чем отличие OAuth 2. 0 от OpenID Connect и что такое SSO.

Спонсор поста

История возникновения OAuth

Авторизацией через социальные сети никого уже не удивишь. Нажимаешь кнопку соц сети, вжух и ты авторизовался на новом сайте. Сайт получил твоё ФИО, фотку и прочие данные. Но так было не всегда.

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

На заре становления Facebook просил у пользователей логин и пароль от Gmail аккаунта, чтобы отправить контактам приглашение. Такой подход имеет большую проблему: логин и пароль дают полный доступ к сервису. Поэтому был разработан стандарт OAuth.

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

🙅‍♂️

OAuth 1.0 не используется. Забудьте о нем. Используйте OAuth 2. 0

Главным недостатком OAuth 1.0 была слишком большая сложность данной версии.

Начнем разбор OAuth 2.0 с ролей. Всего есть 4 роли:

• Владелец ресурса.
• Клиент.
• Сервер ресурсов.
• Авторизационный сервер.

Далее мы рассмотрим каждую из ролей.

Владелец ресурса
Ресурсом являются данные, например ФИО, фотография, ваши сообщения в соц сетях, и прочее. Владелец ресурса это пользователь. При межсерверном общении владельцем ресурса может быть один из серверов.

Сервер ресурсов
На сервере ресурсов лежат ваши данные. В случае с примером выше ваши контакты Gmail это ресурс, а лежат они на серверах Gmail.

Клиент
Клиент это сервис, которому требуется доступ к вашим ресурсам. Например, Facebook требуется доступ к контактам Gmail.

Авторизационный сервер
В данном примере он принадлежит Google, так как он хранит ваши данные.

Стандарт не запрещает вам объединить Сервер ресурсов и Авторизационный сервер

Базовая схема протокола

OAuth 2. 0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров.

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

Весь смысл в том, что Клиент должен получить каким-то образом от авторизационного сервера access_token. Способов этих четыре, о них мы поговорим дальше. Используя этот access_token Клиент может использовать его в запросах к Серверу ресурсов, чтобы получать какие-то данные.

Access Token

Это строка, которая является альтернативой логину и паролю.

Особенности Access Token:

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

Помимо access_token Авторизационный сервер может выдавать также refresh_token. Это токен, который позволяет запросить новый access_token без участия Владельца ресурсов. Время жизни у такого токена намного больше access_token и его потеря гораздо серьезнее.

Вернемся к базовой схеме. Авторизационный сервер должен знать про каждого клиента, который делает к нему запрос. То есть, каждый клиент должен быть зарегистрирован. Зарегистрировав клиента мы получаем client_id и client_secret и обязаны передавать, как минимум client_id в каждом запросе.

Не все клиенты могут гарантировать сохранность client_secret, поэтому он есть не у всех. Например, SPA без бэкенда, теоретически достать оттуда можно что угодно.

Существует возможность регистрировать клиентов динамически: RFC 7591 и RFC 7592.

Способы получения Access Token

Всего есть 4 способа:

• По авторизационному коду (Authorization Code Grand). Самый сложный и самый надежный способ.
• Неявно (Implicit)
• По логину и паролю пользователя (Resource Owner Password Credential). Только для безопасных клиентов, заслуживающих полного доверия.
• По данным клиента (Client Credentials). Получаем токен по client_id и client_secret.

Client Credentials

Начнем разбор с самой простой схемы. Этот способ придуман для межсерверного взаимодействия. У нас есть два сервера API1 и API2, и им надо как-то общаться.

1. API 1 идет в авторизационный сервер передает туда client_id и client_secret.

curl --request POST \
 --url 'https://YOUR_DOMAIN/oauth/token' \
 --header 'content-type: application/x-www-form-urlencoded' \
 --data grant_type=client_credentials \
 --data client_id=YOUR_CLIENT_ID \
 --data client_secret=YOUR_CLIENT_SECRET \
 --data audience=YOUR_API_IDENTIFIER

2. Взамен API 1 получает access_token, с помощью которого может обратиться к API 2.

{
    "access_token": "eyJz93a...k4laUWw",
    "token_type": "Bearer",
    "expires_in": 86400
}

3. API 1 обращается к API 2.

curl --request GET \
--url https://api2.com/api \
--header 'authorization: Bearer ACCESS_TOKEN' \
--header 'content-type: application/json'

4. API 2 получает запрос с access_token и обращается к авторизационному серверу для проверки действительности переданного токена (RFC 7662).

Resource Owner Password Credential

🙅‍♂️

Эта схема не рекомендуется к использованию! В стандарте так и написано, если вы никакие другие схемы не можете сделать, то используйте эту.

1. Владелец ресурсов передает свой логин и пароль Клиенту.
2. Клиент отправляет Авторизационному серверу логин и пароль клиента, а так же свой client_id и client_secret.

curl -d "grant_type=password" \
    -d "client_id=3MVG9QDx8IKCsXTFM0o9aE3KfEwsZLvRt" \
    -d "client_secret=4826278391389087694" \
    -d "username=ryan%40ryguy.com" \
    -d "password=_userspassword__userssecuritytoken_" \
    https://as.com/oauth3/token

3. Если предоставленные пользователем учетные данные успешно аутентифицированы, сервер авторизации вернет ответ application/json, содержащий access_token:

{
    "id":"https://as.com/id/00DU0000000Io8rMAC/005U0000000hMDCIA2",
    "issued_at":"1316990706988",
    "instance_url":"https://na12. salesforce.com",
    "signature":"Q2KTt8Ez5dwJ4Adu6QttAhCxbEP3HyfaTUXoNI=",
    "access_token":"00DU0000000Io8r!AQcKbNiJPt0OCSAvxU2SBjVGP6hW0mfmKH07QiPEGIX"
}

Authorization Code Grand

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

👍

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

1. Пользователь на сайте нажимает кнопку авторизации, например через Facebook.
2. Происходит редирект на авторизационный сервер.
3. Если активной сессии нет, то Пользователь должен залогиниться. Если активная сессия есть, то просто подтвердить авторизацию.

Пример авторизационного запроса

https://YOUR_DOMAIN/authorize
     ?response_type=code
     &client_id=YOUR_CLIENT_ID
     &redirect_uri=https://YOUR_APP/callback
     &scope=SCOPE
     &audience=API_AUDIENCE
     &state=STATE

4. Если все пойдет хорошо, вы получите ответ HTTP 302. Код авторизации включен в конце URL-адреса: в параметре ?code=SplewFEFofer

HTTP/1.1 302
Found Location: https://YOUR_APP/callback?code=AUTHORIZATION_CODE&state=xyzABC123

Так как code попадает в браузер и ничем не защищен, то это точка уязвимости. Поэтому на авторизационный код накладываются следующие ограничения:

• Код одноразовый
• Время жизни кода очень мало

5. Теперь, когда у вас есть код авторизации, вы должны обменять его на токены. Используя извлеченный код авторизации из предыдущего шага, вам нужно будет выполнить POST на URL-адрес токена.

curl --request POST \
    --url 'https://YOUR_DOMAIN/oauth/token' \
    --header 'content-type: application/x-www-form-urlencoded' \
    --data 'grant_type=authorization_code' \
    --data 'client_id=YOUR_CLIENT_ID' \
    --data 'client_secret=YOUR_CLIENT_SECRET' \
    --data 'code=YOUR_AUTHORIZATION_CODE' \
    --data 'redirect_uri=https://YOUR_APP/callback'

6. Если все пойдет хорошо, вы получите ответ HTTP 200 с полезной нагрузкой, содержащей значения access_token, refresh_token, id_token и token_type:

{
    "access_token": "eyJz93a...k4laUWw",
    "refresh_token": "GEbRxBN...edjnXbL",
    "id_token": "eyJ0XAi...4faeEoQ",
    "token_type": "Bearer"
}

7. Чтобы вызвать ваш API из обычного веб-приложения, приложение должно передать полученный токен доступа в заголовке авторизации вашего HTTP-запроса.

curl --request GET \
    --url https://myapi.com/api \
    --header 'authorization: Bearer ACCESS_TOKEN' \
    --header 'content-type: application/json'

Implicit Grant

Теперь у нас сайт без бэкенда — SPA.

1. Пользователь на сайте жмет на кнопку, происходит редирект на сервер авторизации.
2. Пользователь вводит логин пароль, если он не авторизован.
3. Происходит редирект обратно, но access_token возвращается в URL сразу: https://domain. com/back_path#access_token=8ijfwWEFFf0wefOofreW6rglk.

Так как access_token попадает в браузер, то существует возможность его достать.

OpenID Connect

OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому. OpenID Connect (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись.

OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO)

Поток (flow) OpenID Connect выглядит так же, как и в случае OAuth 2.0. Единственная разница в том, что в первичном запросе используемый конкретный scope — openid, — а Клиент в итоге получает как access_token, так и id_token.

ID Token — это особым образом отформатированная строка символов — JSON Web Token или JWT. Сторонним наблюдателям JWT может показаться непонятной абракадаброй, однако Клиент может извлечь из JWT различную информацию, такую как ID, имя пользователя, время входа в учетную запись, срок окончания действия ID Token’а, наличие попыток вмешательства в JWT.

Что такое JWT токен?

Эта статья посвящена детальному разбору JWT и его возможностей. Мы изучим структуру токена и построим его с нуля. Затем рассмотрим наиболее распространенные способы использования.

struchkov.devStruchkov Mark

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

Заключение

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

OAuth

На этой странице показано, как аутентифицировать клиентов с помощью JAR REST API с помощью OAuth (1.0a). Мы объясним, как OAuth работает с Jira и проведем вас по примеру использования OAuth для аутентификации приложения Java (потребителя) с JRE (ресурсом) REST API для пользователя (владельца ресурса).

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

Покажите мне код!

Вы можете найти код для окончательного вывода этого руководства по Bitbucket (найдите каталог Java).

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

Также обратите внимание, что репозиторий содержит каталоги с примерами для Node.js, PHP, Python, Perl и Ruby.

Выбор метод аутентификации

Вы выбрали правильный метод аутентификации?

Принимая во внимание базовую аутентификацию? Мы не рекомендуем использовать базовую аутентификацию вообще, за исключением инструментов, таких как личные скрипты или боты. Это может быть проще реализовать, но гораздо менее безопасно. Имя пользователя и пароль отправляются повторно с запросами и кэшируются в веб-браузере. Даже если учетные данные отправляются через SSL / TLS, эти протоколы все еще могут быть скомпрометированы.

Этот учебник был последний раз проверен с помощью Jira Server 7.0.

Обзор

OAuth — это протокол аутентификации, который позволяет пользователю (то есть владельцу ресурса) предоставлять стороннему приложению (то есть потребителю / клиенту) доступ к их информации на другом сайте (то есть ресурсе). Jira использует 3-сторонний OAuth (3LO), что означает, что пользователь участвует в процессе аутентификации, разрешая доступ к своим данным на ресурсе (в отличие от двухстороннего OAuth, где пользователь не участвует).

Роли

Это роли в процессе аутентификации OAuth и как они связаны с аутентификацией с Jira:

Ресурс

КАРТИНКА\

Если вы интегрируете клиентское приложение с Jira, тогда Jira считается «ресурсом».

Владелец ресурса

КАРТИНКА

Поскольку Jira является «ресурсом», пользователь Jira считается «владельцем ресурса» для запроса аутентификации.

Потребитель

РИСУНОК

Клиентское приложение регистрируется как потребитель, создавая ссылку на приложение (использующую OAuth) в Jira, которая ссылается на клиента.

Обработка

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

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

РИСУНОК

Смотрите это в действии

Прежде чем мы посмотрим на код, давайте посмотрим, как работает процесс аутентификации OAuth. Это будет практическое пошаговое руководство, в котором вы настроите Jira так, чтобы клиент-образец мог аутентифицироваться против него с помощью OAuth. Вы также будете использовать образец клиента для инициирования «танца OAuth», а затем, наконец, выполнить аутентифицированный запрос к API Jira REST.

Прежде чем вы начнете

Чтобы завершить этот учебник, вам нужно знать и делать следующее:

1. Основные знания о том, как использовать API REST, например, запросы, ответы, заголовки.
2. Основное понимание Jira.
3. Если вы хотите запустить пример Java, вам понадобится пример разработки Jira, Maven (3.x) и недавняя версия Java (например, Oracle JDK 1.8).
4. Если у вас еще нет кода приложения клиента OAuth, клонируйте его здесь: https://bitbucket.org/atlassian_tutorial/atlassian-oauth-examples (в каталоге Java).
5. После того, как у вас есть код, создайте клиент, выполнив следующую команду в корне проекта:

mvn clean compile assembly:single

6. Перейдите в  каталог target в проекте и запустите:

java -jar OAuthTutorialClient-1. 0.jar requestToken

Игнорировать исключение на выходе. Вам просто нужно сделать это, чтобы сгенерировать файл config.properties, который вы будете использовать позже.

Шаг 1. Настройте клиентское приложение как потребитель OAuth.

В Jira потребители OAuth представлены ссылками на приложения. В ссылках приложения используется OAuth с подписью RSA-SHA1 для аутентификации. Это означает, что для подписи запросов используется закрытый ключ, а не секрет токена тайны / потребителя OAuth. На следующих шагах вы создадите пару общих / закрытых ключей RSA, а затем создайте новую ссылку приложения в Jira, которая использует ключ.

Создание пары открытых и закрытых ключей RSA

1. В окне терминала запустите следующие команды openssl. Вы можете сделать это в любом месте вашей файловой системы.

openssl genrsa -out jira_privatekey.pem 1024
openssl req -newkey rsa:1024 -x509 -key jira_privatekey.pem -out jira_publickey.cer -days 365
openssl pkcs8 -topk8 -nocrypt -in jira_privatekey. pem -out jira_privatekey.pcks8
openssl x509 -pubkey -noout -in jira_publickey.cer  > jira_publickey.pem

Это генерирует 1024-битный закрытый ключ, создает сертификат X509 и извлекает закрытый ключ (формат PKCS8) в файл jira \ _privatekey.pcks8. Затем он извлекает открытый ключ из сертификата в файл jira \ _publickey.pem.

2. Скопируйте закрытый ключ из файла jira \ _privatekey.pcks8 в буфер обмена.

3. Перейдите в  каталог target в образце проекта клиента OAuth. Откройте файл config.properties и внесите следующие изменения:
   1. Вставьте закрытый ключ из вашего буфера обмена по значению поля private_key. Удалите все разрывы строк.
   2. Измените jira_home на URL вашего примера разработки Jira, например https://example-dev1.atlassian.net.
   3. Не меняйте consumer_key, который должен быть установлен на «OauthKey».
4. Сохраните файл config.properties.

Настройка клиентского приложения как потребителя в Jira

1. В Jira нажмите шестеренка>«Приложения»> «Ссылки приложения».
2. В поле «Введите URL-адрес приложения, которое хотите связать» введите любой URL-адрес, например http://example.com/, а затем нажмите «Создать новую ссылку».

Вы получите предупреждение о том, что «от введенного вами URL-адреса не получено ответа». Игнорируйте его и нажмите «Продолжить».

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

РИСУНОК

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

4. На следующем экране диалогового окна «Ссылки приложений» введите данные потребителя для образца клиента:

• Consumer key = OauthKey Потребительский ключ = OauthKey
• Consumer name = Example Jira app Имя потребителя = Пример приложения Jira
• Public key = Copy the public key Открытый ключ = Скопируйте открытый ключ из созданного ранее файла jira \ _publickey. pem и вставьте его в это поле.

                           РИСУНОК

5. Нажмите «Продолжить». Вы должны получить ссылку на приложение, которая выглядит так:

РИСУНОК

Это оно! Теперь вы настроили образец-клиента в качестве потребителя OAuth в Jira.

Шаг 2. Сделайте «танец OAuth»

«Танец OAuth» — это термин, который используется для описания процесса получения токена доступа из ресурса, который потребитель может использовать для доступа к информации о ресурсе. Это включает в себя «танец», где между потребителем, владельцем ресурса и ресурсом передаются разные токены (см. Обзор OAuth в начале страницы).

1. В своем терминале перейдите в  каталог target  проекта примера клиента OAuth, если его еще нет.
2. Выполните следующую команду:

java -jar OAuthTutorialClient-1.0.jar requestToken

Эта команда запрашивает неавторизованный токен запроса из вашего экземпляра Jira.

Вы увидите следующий результат с деталями вашего нового токена запроса:

Token:          ec3dj4byySM5ek3XW7gl7f4oc99obAlo
Token Secret:   OhONj0eF7zhXAMKZLbD2Rd3x7Dmxjy0d
Retrieved request token.  go to https://jira101.atlassian.net/plugins/servlet/oauth/authorize?oauth_token=ec3dj4byySM5ek3XW7gl7f4oc99obAlo to authorize it

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

3. В своем браузере перейдите к URL-адресу, указанному в выводе терминала. Появится следующее диалоговое окно.

РИСУНОК

4. Нажмите «Разрешить». Это разрешит токен запроса.

В браузере вы увидите следующий результат:

Доступ одобрен
Вы успешно разрешили «Пример JIRA-приложения». Ваш код подтверждения - «qTJkPi». Вам нужно будет
введите этот точный текст при появлении запроса. Вы должны записать это значение до закрытия окна браузера.

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

5. В своем терминале запустите следующую команду:

java -jar OAuthTutorialClient-1.0.jar accessToken qTJkPi

Вам нужно будет заменить код проверки примера (qTJkPi) своим собственным кодом подтверждения с предыдущего шага.

В вашем терминале вы увидите следующий вывод:

Access Token:           W1jjOV4sq2iEqxO4ZYZTJVdgbjtKc2ye

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

Теперь у нас есть то, что мы хотели от танца OAuth: токен доступа, который мы можем использовать, чтобы сделать аутентифицированный запрос к API Jira REST.

Шаг 3. Сделайте аутентифицированный запрос API Jira REST

Код доступа — это все, что нам нужно, чтобы сделать аутентифицированный запрос API Jira REST. Запросы принимаются в качестве пользователя, который разрешил токен первичного запроса. Токен доступа будет сохраняться в течение 5 лет, если он не будет отменен.

1. Пример клиента OAuth только делает запросы GET. Чтобы использовать его, выполните следующую команду:

java -jar OAuthTutorialClient-1.0.jar request <URL for GET method>

Вам нужно будет подставить <URL for REST method> URL-адресом метода REST, который вы пытаетесь вызвать.

В коде пример клиента OAuth фактически сохраняет код доступа в файле config.properties, когда он получен. Когда запрос выполняется, пример  клиента передает сохраненный код доступа, а не вводит его.

Вот пример запроса к  GET  (ПОЛУЧИТЬ) задачи, используя пример клиента OAuth. Следующая команда получает JJ-2 с помощью Jira REST API:

java -jar OAuthTutorialClient-1.0.jar request http://localhost:8080/rest/api/latest/issue/JJ-2

Вышеупомянутый метод возвращает такую задачу:

{
   "expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations",
   "self": "<a href="http://localhost:8080/rest/api/latest/issue/10300">http://localhost:8080/rest/api/latest/issue/10300</a>",
   "id": "10300",
   "fields": {
     "issuetype": {
       "avatarId": 10803,
       "name": "Bug",
       "self": "<a href="http://localhost:8080/rest/api/2/issuetype/1">http://localhost:8080/rest/api/2/issuetype/1</a>",
       "description": "A problem which impairs or prevents the functions of the product. ",
       "id": "1",
       "iconUrl": "<a href="http://localhost:8080/secure/viewavatar?size=xsmall&avatarId=10803&avatarType=issuetype">http://localhost:8080/secure/viewavatar?size=xsmall&avatarId=10803&avatarType=issuetype</a>",
       "subtask": false
     },
     "timespent": null,
     "project": {
       "avatarUrls": {
         "48x48": "<a href="http://localhost:8080/secure/projectavatar?pid=10200&avatarId=10700">http://localhost:8080/secure/projectavatar?pid=10200&avatarId=10700</a>",
         "24x24": "<a href="http://localhost:8080/secure/projectavatar?size=small&pid=10200&avatarId=10700">http://localhost:8080/secure/projectavatar?size=small&pid=10200&avatarId=10700</a>",
         "16x16": "<a href="http://localhost:8080/secure/projectavatar?size=xsmall&pid=10200&avatarId=10700">http://localhost:8080/secure/projectavatar?size=xsmall&pid=10200&avatarId=10700</a>",
         "32x32": "<a href="http://localhost:8080/secure/projectavatar?size=medium&pid=10200&avatarId=10700">http://localhost:8080/secure/projectavatar?size=medium&pid=10200&avatarId=10700</a>"
       },
       "name": "JIRA Junior",
       "self": "<a href="http://localhost:8080/rest/api/2/project/10200">http://localhost:8080/rest/api/2/project/10200</a>",
       "id": "10200",
       "key": "JJ"
     },
     "fixVersions": [],
     "aggregatetimespent": null,
     "resolution": null,
     "customfield_10500": null,
     "customfield_10700": "com. atlassian.servicedesk.plugins.approvals.internal.customfield.ApprovalsCFValue@c8d588",
     "resolutiondate": null,
     "workratio": -1,
     "lastViewed": "2016-08-01T11:23:39.481+1000",
     "watches": {
       "self": "<a href="http://localhost:8080/rest/api/2/issue/JJ-2/watchers">http://localhost:8080/rest/api/2/issue/JJ-2/watchers</a>",
       "isWatching": true,
       "watchCount": 1
     },
     "created": "2013-05-29T13:56:24.224+1000",
     "customfield_10020": null,
     "customfield_10021": "Not started",
     "priority": {
       "name": "Major",
       "self": "<a href="http://localhost:8080/rest/api/2/priority/3">http://localhost:8080/rest/api/2/priority/3</a>",
       "iconUrl": "<a href="http://localhost:8080/images/icons/priorities/major.svg">http://localhost:8080/images/icons/priorities/major.svg</a>",
       "id": "3"
     },
     "customfield_10300": null,
     "customfield_10102": null,
     "labels": [],
     "customfield_10016": null,
     "customfield_10017": null,
     "customfield_10018": null,
     "customfield_10019": null,
     "timeestimate": null,
     "aggregatetimeoriginalestimate": null,
     "versions": [],
     "issuelinks": [],
     "assignee": {
       "emailAddress": "alana@<a href="http://example. com">example.com</a>",
       "avatarUrls": {
         "48x48": "<a href="https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=48">https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=48</a>",
         "24x24": "<a href="https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=24">https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=24</a>",
         "16x16": "<a href="https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=16">https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=16</a>",
         "32x32": "<a href="https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=32">https://secure.gravatar.com/avatar/b259e2a7fd37a83b02015192ee247e96?d=mm&s=32</a>"
       },
       "displayName": "Alana Example",
       "name": "alana",
       "self": "<a href="http://localhost:8080/rest/api/2/user?username=alana">http://localhost:8080/rest/api/2/user?username=alana</a>",
       "active": true,
       "timeZone": "Australia/Sydney",
       "key": "alana"
     },
     "updated": "2016-08-01T11:23:38. 022+1000",
     "status": {
       "name": "Open",
       "self": "<a href="http://localhost:8080/rest/api/2/status/1">http://localhost:8080/rest/api/2/status/1</a>",
       "description": "The issue is open and ready for the assignee to start work on it.",
       "iconUrl": "<a href="http://localhost:8080/images/icons/statuses/open.png">http://localhost:8080/images/icons/statuses/open.png</a>",
       "id": "1",
       "statusCategory": {
         "colorName": "blue-gray",
         "name": "To Do",
         "self": "<a href="http://localhost:8080/rest/api/2/statuscategory/2">http://localhost:8080/rest/api/2/statuscategory/2</a>",
         "id": 2,
         "key": "new"
       }
     },
     "components": [],
     "timeoriginalestimate": null,
     "description": "The logo is currently a light cerise. I'd like to see it with a deep pink color.",
     "customfield_10012": null,
     "customfield_10013": null,
     "customfield_10014": null,
     "timetracking": {},
     "customfield_10015": null,
     "customfield_10600": null,
     "customfield_10006": "10",
     "customfield_10601": null,
     "customfield_10007": [
       "com. atlassian.greenhopper.service.sprint.Sprint@dc6300[id=1,rapidViewId=<null>,state=CLOSED,name=Sprint 1,goal=<null>,startDate=2013-07-26T11:31:09.530+10:00,endDate=2013-08-09T11:31:09.530+10:00,completeDate=2013-07-26T11:31:46.489+10:00,sequence=1]",
       "com.atlassian.greenhopper.service.sprint.Sprint@6b3e17[id=2,rapidViewId=<null>,state=ACTIVE,name=Sprint 2,goal=<null>,startDate=2013-08-22T11:35:33.759+10:00,endDate=2013-12-12T11:35:00.000+11:00,completeDate=<null>,sequence=2]"
     ],
     "customfield_10008": null,
     "attachment": [],
     "aggregatetimeestimate": null,
     "summary": "JIRA Junior logo is not pink enough",
     "creator": {
       "emailAddress": "admin@<a href="http://example.com">example.com</a>",
       "avatarUrls": {
         "48x48": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48</a>",
         "24x24": "<a href="https://secure. gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24</a>",
         "16x16": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16</a>",
         "32x32": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32</a>"
       },
       "displayName": "Administrator",
       "name": "admin",
       "self": "<a href="http://localhost:8080/rest/api/2/user?username=admin">http://localhost:8080/rest/api/2/user?username=admin</a>",
       "active": true,
       "timeZone": "Australia/Sydney",
       "key": "admin"
     },
     "subtasks": [],
     "reporter": {
       "emailAddress": "admin@<a href="http://example.com">example.com</a>",
       "avatarUrls": {
         "48x48": "<a href="https://secure. gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48</a>",
         "24x24": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24</a>",
         "16x16": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16</a>",
         "32x32": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32</a>"
       },
       "displayName": "Administrator",
       "name": "admin",
       "self": "<a href="http://localhost:8080/rest/api/2/user?username=admin">http://localhost:8080/rest/api/2/user?username=admin</a>",
       "active": true,
       "timeZone": "Australia/Sydney",
       "key": "admin"
     },
     "customfield_10000": null,
     "aggregateprogress": {
       "total": 0,
       "progress": 0
     },
     "customfield_10001": null,
     "customfield_10200": "0|10001s:",
     "customfield_10002": null,
     "customfield_10003": null,
     "customfield_10400": null,
     "environment": null,
     "duedate": null,
     "progress": {
       "total": 0,
       "progress": 0
     },
     "comment": {
       "total": 1,
       "comments": [{
         "author": {
           "emailAddress": "admin@<a href="http://example. com">example.com</a>",
           "avatarUrls": {
             "48x48": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48</a>",
             "24x24": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24</a>",
             "16x16": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16</a>",
             "32x32": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32</a>"
           },
           "displayName": "Administrator",
           "name": "admin",
           "self": "<a href="http://localhost:8080/rest/api/2/user?username=admin">http://localhost:8080/rest/api/2/user?username=admin</a>",
           "active": true,
           "timeZone": "Australia/Sydney",
           "key": "admin"
         },
         "created": "2013-06-04T16:11:24. 505+1000",
         "updateAuthor": {
           "emailAddress": "admin@<a href="http://example.com">example.com</a>",
           "avatarUrls": {
             "48x48": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=48</a>",
             "24x24": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=24</a>",
             "16x16": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=16</a>",
             "32x32": "<a href="https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32">https://secure.gravatar.com/avatar/4beac5df66a475580809e0?d=mm&s=32</a>"
           },
           "displayName": "Administrator",
           "name": "admin",
           "self": "<a href="http://localhost:8080/rest/api/2/user?username=admin">http://localhost:8080/rest/api/2/user?username=admin</a>",
           "active": true,
           "timeZone": "Australia/Sydney",
           "key": "admin"
         },
         "self": "<a href="http://localhost:8080/rest/api/2/issue/10300/comment/10100">http://localhost:8080/rest/api/2/issue/10300/comment/10100</a>",
         "id": "10100",
         "body": "Hi [~william] JIRA is *super fun* (see JJ-1).  Alana is going to fix the logo.",
         "updated": "2013-06-12T21:55:34.882+1000"
       }],
       "maxResults": 1,
       "startAt": 0
     },
     "votes": {
       "hasVoted": false,
       "self": "<a href="http://localhost:8080/rest/api/2/issue/JJ-2/votes">http://localhost:8080/rest/api/2/issue/JJ-2/votes</a>",
       "votes": 0
     }
   },
   "key": "JJ-2"
 }

Поздравления! Теперь вы знаете, как использовать OAuth, чтобы сделать аутентифицированный запрос API Jira REST.

Советы по разработке

Вы можете реализовать OAuth несколькими способами, в зависимости от того, что вы создаете. Тем не менее, мы рекомендуем вам просмотреть исходный код нашего образца Java OAuth-клиента, чтобы получить представление о том, как он реализован, независимо от технологий, которые вы используете.

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

• Используйте библиотеки OAuth. Вместо того, чтобы полностью внедрять все, существует ряд библиотек OAuth, которые вы можете использовать в коде на OAuth.net. Образец клиента OAuth использует клиентскую библиотеку Google OAuth для Java.
• OAuth 2.0 не поддерживается. В настоящее время поддерживается только OAuth 1.0a для аутентификации в Jira REST API.
• Запросы на токены должны быть сделаны с использованием HTTP POST.
• Установите обратный вызов на «oob» (то есть вне диапазона) при создании токена запроса, если вы хотите показать секретный токен пользователю. См. GetAndAuthorizeTemporaryToken в JIRAOAuthClient.java в образце клиента OAuth для этого примера. Затем вы можете установить обратный вызов на какой-либо другой URL-адрес после того, как пользователь авторизует токен, чтобы Jira отправил токен и секрет на этот URL-адрес.
• При выполнении запросов передайте токен доступа OAuth в заголовок запроса, не передавайте его в тело запроса. Если вы передадите данные OAuth в тело запроса, он вернет ошибку «400 Bad Request» для большинства методов. Вы должны передать данные в заголовке вместо этого, например, Authorization: Bearer {access_token}.

Следующие шаги

Прочтите обзор безопасности, чтобы узнать разницу между аутентификацией и авторизацией, а также то, как пользователи авторизованы в Jira.Ознакомьтесь с API Jira REST:

• API-интерфейс REST для платформы Jira
• API REST Jira Software Server
• API REST службы поддержки Jira

По материалам Atlassian JIRA  Server Developer OAuth

OAuth | это… Что такое OAuth?

Логотип OAuth

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

Преимущества OAuth-авторизации

Безопасность

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

Повышение лояльности пользователей

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

Удобство для пользователей

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

История

OAuth 1.0

OAuth возник в ноябре 2006 года, когда Блейн Кук (англ. Blaine Cook) разрабатывал реализацию протокола OpenID для сервиса микроблогов Twitter. Совместно с Крисом Мессиной (англ. Chris Messina) он искал путь использовать OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Девидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как Flickr Auth, Google AuthSub и Yahoo! BBAuth, после чего пришли к заключению, что существует необходимость в новом открытом протоколе.

В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний Google и AOL (которая в это же время представила свой собственный протокол OpenAuth). Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в Инженерном совете Интернета.

15 апреля 2009 года Twitter предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Sign-in with Twitter» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней был обнаружен потенциальный эксплоит, затрагивающий все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновленную спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня.

В апреле 2010 года был выпущен информационный документ RFC 5849^[1], посвященный стандарту OAuth. ^[2]

OAuth 2.0

В 2010 году началась работа над совершенно новой версией протокола OAuth 2.0^[3], которая не будет обратно совместимой с OAuth 1.0. В октябре 2012 года структура OAuth 2.0 было опубликована в RFC 6749, и использование носителя токена в RFC 6750, оба стандарта отслеживают запросы на комментарии. Дополнительные документы RFC еще разрабатываются.

Предпосылок для создания OAuth 2.0 было несколько. В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth — упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трех методов (называемых потоками — flows) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым. В него планируется добавить^[4]:

• 6 новых потоков.

Поток пользователя – агента (User-Agent Flow)  — для клиентов, работающих внутри агента пользователя (обычно веб-браузер).

Поток веб – сервера (Web Server Flow) — для клиентов, которые являются частью веб-приложения сервера, доступные через запросы HTTP.

Поток устройства (Device Flow) — подходит для клиентов, выполняющихся на ограниченных устройствах, но там, где конечный пользователь имеет отдельный доступ к браузеру на другом компьютере или устройстве.

Поток имени пользователя и пароля(Username and Password Flow) — используется в тех случаях, когда пользователь доверяет клиенту обрабатывать свои полномочия, но он по-прежнему нежелательно разрешит клиенту сохранить имя и пароль пользователя. Этот поток подходит только когда есть высокая степень доверия между пользователем и клиентом.

Поток клиентских полномочий (Client Credentials Flow) — клиент использует свои полномочия для получения токена.

Поток утверждения (Assertion Flow) — клиент представляет утверждение, такие как утверждение SAML к серверу авторизации в обмен на токен.

Приложения, работающие на настольном компьютере или мобильном устройстве может быть реализованы с использованием выше сказанных потоков.

• Токен на предъявителя.

Метод авторизации аналогичен существующему способу авторизации с помощью cookie. В этом случае токен непосредственно используется как секрет (сам факт наличия токена авторизует клиента) и передается через HTTPS. Это позволяет получать доступ к API посредством простых скриптов (например, с использованием cURL).

• Упрощенная подпись.

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

• Короткоживущие токены с долговременной авторизацией.

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

• Разделение ролей.

За авторизацию и за предоставление доступа к API могут отвечать разные сервера.

Стоит отметить, что, хотя стандарт OAuth 2.0 ещё не утвержден, он уже используется некоторыми сервисами. Например, Graph API социальной сети Facebook поддерживает только OAuth 2.0.

Отличие OAuth от OpenID

Существует ошибочное мнение, что OAuth является расширением протокола OpenID. На самом деле это не так. Хотя OpenID и OAuth имеют много общего, последний является самостоятельным протоколом, никак не связанным с OpenID.

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

OpenID является средством аутентификации: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдает. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.

Термины

Клиент, сервер и владелец ресурса

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

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

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

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

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

Методы создания подписей

OAuth поддерживает 3 метода создания подписей, используемых для подписывания и проверки запросов: PLAINTEXT, HMAC-SHA1 и RSA-SHA1. PLAINTEXT тривиален в использовании и занимает значительно меньше времени для вычисления, но он может быть только безопасен над HTTPS или аналогичными защищенными каналами. HMAC-SHA1 предлагает простой и общий алгоритм, который доступен на большинстве платформ, но не на всех устаревших устройствах и использует симметричный общий ключ. RSA-SHA1 обеспечивает повышенную безопасность с помощью пары ключей, но является более сложным и требует генерацию ключей.^[5]

Метка времени и Nonce

Чтобы предотвратить угрозу запросов повторного использования , OAuth используется nonce и метку времени. Термин «nonce» означает что, данное время используется один раз и является уникальным случайным набором букв и цифр, который предназначен для уникальной идентификации каждого подписанного запроса. Имея уникальный идентификатор для каждого запроса, поставщик услуг сможет помешать запросы повторного использования. Это означает, что клиент генерирует уникальную строку для каждого отправляемого на сервер запроса, а сервер отслеживает все использованные nonce для предотвращения их использования во второй раз.

Использование nonce может быть очень дорогостоящим для сервера, так как они требуют постоянного хранения всех полученных nonce. Для того, чтобы реализация была проще, OAuth добавляет метку времени для каждого запроса, который позволяет серверу сохранить только nonce в течение ограниченного времени. Когда приходит запрос с меткой времени, которое раньше, чем сохраненное время, он отвергается как сервер больше не имеет nonce с такого времени.^[5]

Полномочия и токены

OAuth используется три вида полномочий: учетные данные клиента (consumer key and secret или client credentials), временные учетные данные (request token and secret или temporary credentials) и токены (access token and secret или token credentials).

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

Токен используется вместо имени и пароля владельца ресурса. Владелец ресурса не поделится своими учетными данными с клиентом, а разрешает серверу выдавать клиенту токен — специальный класс учетных данных, которые представляют доступ гранта. Клиент использует токен для доступа к защищенному ресурсу, не зная пароля владельца ресурсов.

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

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

Как работает OAuth

Схема работы протокола OAuth

Поясним работу протокола OAuth на примере^[1]. Допустим, что пользователь (владелец ресурсов) хочет распечатать свои фотографии (ресурсы), загруженные на сайт «photos.example.net» (сервер), при помощи сервиса печати «printer.example.net» (клиент).

1. Клиент посредством протокола HTTPS отправляет серверу запрос, который содержит идентификатор клиента, метку времени, адрес обратного вызова по которому нужно вернуть токен, используемый тип цифровой подписи и саму подпись.
2. Сервер подтверждает запрос и отвечает клиенту токеном доступа (Access Token) и частью разделённого секрета.
3. Клиент передает токен владельцу ресурсов (пользователю) и перенаправляет его на сервер для прохождения авторизации.
4. Сервер, получив от пользователя токен, запрашивает у него его логин и пароль, и в случае успешной аутентификации просит пользователя подтвердить доступ клиента к ресурсам (авторизация), после чего пользователь перенаправляется сервером к клиенту.
5. Клиент передает серверу токен посредством протокола TLS и запрашивает доступ к ресурсам.
6. Сервер подтверждает запрос и отвечает клиенту новым токеном доступа.
7. Используя новый токен, клиент обращается к серверу за ресурсами.
8. Сервер подтверждает запрос и предоставляет ресурсы.

Данный пример описывает поток с кодом подтверждения (Authorization Code Flow). Помимо этого в стандарте OAuth 2.0 описаны следующие потоки:

• Поток неявного доступа (Implicit Grant Flow)

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

• Поток с обновляемым токеном (Refreshing an Expired Access Token Flow)

Отличия данного потока от приведённого примера в следующем: на шаге 2 сервер помимо токена доступа, который имеет ограниченное время жизни, выдает токен обновления; на шаге 8 сервер проверяет, является ли токен доступа валидным (в смысле истечения времени жизни), и в зависимости от этого либо предоставляет доступ к ресурсам, либо требует обновления токена доступа (который предоставляется при предъявлении токена обновления).

• Поток с предоставлением клиенту пароля (Resource Owner Password Credentials Flow)

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

• Поток клиентских полномочий (Client Credentials Flow)

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

OAuth поддерживает два метода аутентификации сообщений от клиента: HMAC-SHA1 и RSA-SHA1. Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «plain text». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол SSL или TLS.

Порталы, использующие OAuth

• Yahoo в начале 2008 года объявила о комплексной поддержке OAuth в Yahoo Fire Eagle API.
• Twitter — с апреля 2009 года.
• Яндекс — с сентября 2010 года доступен в проектах Я.ру, Яндекс.Фотки, Яндекс.Директ, Яндекс.Подписки, Яндекс.Метрика и Яндекс.Почта для домена^[6].
• Mail.ru — с февраля 2011 года авторизация в Mail.Ru API переведена на стандарт OAuth 2.0^[7].
• Microsoft летом 2011 года объявил о поддержке OAuth 2.0 для всех основных сервисов Windows Live (более 500 миллионов активных пользователей), включая Windows Live ID, Hotmail (календарь, контакты), SkyDrive (CRUD-доступ к документам, фотографиям, аудио и видео-файлам, в бета-версии), Windows Live Messenger (присутствие, статус и обмен сообщениями).
• Flickr — c июня 2011 года^[8].
• Facebook — с сентября 2011 года.
• Google^[9]
• FriendFeed^[10]
• Dropbox^[11]
• ВКонтакте^[12]
• Одноклассники. ru^[12]
• GitHub^[13]
• SoundCloud^[14]
• Foursquare^[15]
• Salesforce.com^[16]
• Dailymotion^[17]
• Vimeo^[18]
• Bitbucket^[19]
• Instagram^[20]

Дискуссия

В июле 2012 года, Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трех лет работы над новым стандартом, и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своем сайте^[21]. Он позже выступил с докладом. ^[22].

Девид Рекордон (англ. David Recordon) позже также вычеркнул своё имя из спецификаций без указания причин. Дик Хардт стал редактором стандарта OAuth3.0, и несмотря на взгляды Эрана Хаммера структура OAuth 2.0 было опубликована в RFC 6749 2012 года.

Примечания

1. ↑ ^{1 2} RFC 5849 The OAuth 1. 0 Protocol
2. ↑ The OAuth 1.0 Guide. History
3. ↑ RFC Draft The OAuth 2.0 Authorization Protocol
4. ↑ Introducing OAuth 2.0
5. ↑ ^{1 2} Security Framework « hueniverse
6. ↑ Яндекс. OAuth-авторизация
7. ↑ OAuth 2.0 как предчувствие
8. ↑ Flickr now Supports OAuth 1.0a
9. ↑ Google. Аутентификация веб-приложений с помощью OAuth
10. ↑ FriendFeed API Documentation
11. ↑ Using OAuth in «PLAINTEXT» mode
12. ↑ ^{1 2} OAuth на практике. Аутентификация и авторизация пользователей сайта через популярные социалки
13. ↑ OAuth
14. ↑ API Reference
15. ↑ Connecting
16. ↑ Setting Up OAuth 2.0
17. ↑ Authentication
18. ↑ Advanced API
19. ↑ Now with OAuth support
20. ↑ Authentication
21. ↑ [ http://hueniverse. com/2012/07/oauth-2-0-and-the-road-to-hell/]
22. ↑ [ http://vimeo.com/52882780/]

См. также

• OpenID
• HTTP
• TLS
• SHA1
• HMAC

Ссылки

• Официальный сайт
• Описание OAuth

Спецификации — OAuth

Текущие активные черновики в рабочей группе OAuth

Активные черновики

Оптимальная текущая практика безопасности OAuth 2.0 черновик-ietf-oauth-темы-безопасности-21	2022-09-27
Протокол вызова поэтапной аутентификации OAuth 2.0 черновик-ietf-oauth-step-up-authn-challenge-03	2022-09-14
OAuth 2.0 для браузерных приложений черновик-ietf-oauth-браузер-приложения-11	2022-09-13
Избирательное раскрытие информации для JWT (SD-JWT) черновик-ietf-oauth-selective-disclosure-jwt-00	2022-08-25
OAuth 2. 0, демонстрирующий доказательство владения на прикладном уровне (DPoP) draft-ietf-oauth-dpop-11 Запрошена публикация	2022-08-10
Платформа авторизации OAuth 2.1 черновик-ietf-oauth-v2-1-06	2022-07-24
Расширенные запросы авторизации OAuth 2.0 draft-ietf-oauth-rar AD Evaluation::Revised I-D Needed	2022-05-05
Ответ JWT для самоанализа токена OAuth draft-ietf-oauth-jwt-introspection-response RFC Ed Queue	2021-09-04

Активные отдельные проекты

RFC

JWK Thumbprint URI RFC 9278	2022-06-01
Идентификатор издателя сервера авторизации OAuth 2. 0 RFC 9207	2022-01-11
Отправленные запросы авторизации OAuth 2.0 RFC 9126	2021-07-29
Платформа авторизации OAuth 2.0: JWT-Secured Authorization Request (JAR) RFC 9101	2021-04-08
Профиль JSON Web Token (JWT) для токенов доступа OAuth 2.0 RFC 9068	2021-05-25
Передовой опыт веб-токена JSON RFC 8725 Передовой опыт	2019-10-13
Индикаторы ресурсов для OAuth 2.0 RFC 8707	2019-09-11
OAuth 2.0 Mutual-TLS Client Authentication и маркеры доступа с привязкой к сертификату RFC 8705	2019-08-23
Обмен токенов OAuth 2. 0 RFC 8693	2019-07-21
Предоставление авторизации устройства OAuth 2.0 RFC 8628	2019-03-11
Метаданные сервера авторизации OAuth 2.0 RFC 8414	2018-03-04
OAuth 2.0 для собственных приложений RFC 8252 Передовой опыт	2017-06-09
Справочные значения метода аутентификации RFC 8176	2017-03-13
Семантика ключа подтверждения владения для веб-токенов JSON (JWT) RFC 7800	2015-12-18
Самоанализ токена OAuth 2.0 RFC 7662	2015-07-03
Ключ подтверждения для обмена кодами общедоступными клиентами OAuth RFC 7636	2015-07-10
Протокол управления динамической регистрацией клиентов OAuth 2. 0 RFC 7592 Экспериментальный	2015-05-05
Протокол динамической регистрации клиентов OAuth 2.0 RFC 7591	2015-05-28
Профиль JSON Web Token (JWT) для аутентификации и авторизации клиента OAuth 2.0 RFC 7523	2014-11-12
Профиль языка разметки подтверждения безопасности (SAML) 2.0 для аутентификации и авторизации клиента OAuth 2.0 RFC 7522	2014-11-12
Платформа утверждений для аутентификации и авторизации клиента OAuth 2.0 предоставляет RFC 7521	2014-10-21
Веб-токен JSON (JWT) RFC 7519	2014-12-09
Отзыв токена OAuth 2. 0 RFC 7009	2013-07-13
Модель угроз OAuth 2.0 и вопросы безопасности RFC 6819 Информационная	2012-10-06
Подпространство имен URN IETF для OAuth RFC 6755 Информационная	2012-07-16
Платформа авторизации OAuth 2.0: использование токена носителя RFC 6750	2012-08-01
Платформа авторизации OAuth 2.0 RFC 6749	2012-08-01

Что, черт возьми, такое OAuth?

Существует много путаницы вокруг того, чем на самом деле является OAuth .

Некоторые люди думают, что OAuth — это процесс входа в систему (например, когда вы входите в приложение с помощью Google Login), а некоторые люди думают об OAuth как о «вещи безопасности» , и на самом деле не знают ничего большего.

Я покажу вам, что такое OAuth, объясню, как он работает, и, надеюсь, оставлю у вас представление о том, как и где OAuth может принести пользу вашему приложению.

Что такое OAuth?

Начнем с высокого уровня. OAuth — это , а не API или служба: это открытый стандарт для авторизации, и любой может его внедрить.

В частности, OAuth — это стандарт, который приложения могут использовать для предоставления клиентским приложениям «безопасного делегированного доступа». OAuth работает через HTTPS и авторизует устройства, API, серверы и приложения с помощью токенов доступа, а не учетных данных.

Существует две версии OAuth: OAuth 1.0a и OAuth 2.0. Эти характеристики полностью отличаются от друг от друга и не могут использоваться вместе: между ними нет обратной совместимости и .

Какой из них популярнее? Отличный вопрос! В настоящее время OAuth 2.0 является наиболее широко используемой формой OAuth. Так что теперь, всякий раз, когда я говорю «OAuth» , я говорю об OAuth 2. 0 — так как вы, скорее всего, будете его использовать.

Почему OAuth?

OAuth создан в ответ на шаблон прямой аутентификации. Этот шаблон стал известен благодаря базовой аутентификации HTTP, когда пользователю предлагается ввести имя пользователя и пароль. Базовая аутентификация по-прежнему используется как примитивная форма аутентификации API для серверных приложений: вместо отправки имени пользователя и пароля на сервер с каждым запросом пользователь отправляет идентификатор ключа API и секрет. До OAuth сайты предлагали вам ввести свое имя пользователя и пароль непосредственно в форму, и они могли входить в систему с вашими данными (например, вашей учетной записью Gmail) как вы. Это часто называют антишаблоном пароля.

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

Федеративное удостоверение стало известно благодаря SAML 2.0, стандарту OASIS, выпущенному 15 марта 2005 г. Это обширная спецификация, но основными ее компонентами являются протокол запроса аутентификации (он же Web SSO) и то, как он упаковывает атрибуты удостоверения и подписывает их. называются утверждениями SAML. Okta делает это с помощью своих чиклетов SSO. Отправляем сообщение, подписываем ассерт, внутри ассерта написано, кто пользователь, и что пришло от Окты. Поставьте на нем цифровую подпись, и все готово.

САМЛ

SAML — это файл cookie сеанса в вашем браузере, который дает вам доступ к веб-приложениям. Он ограничен в типах профилей устройств и сценариев, которые вы, возможно, захотите использовать вне веб-браузера.

Когда в 2005 году был запущен SAML 2.0, это имело смысл. Однако с тех пор многое изменилось. Теперь у нас есть современные веб-платформы и платформы для разработки нативных приложений. Существуют одностраничные приложения (SPA), такие как Gmail/Google Inbox, Facebook и Twitter. Их поведение отличается от поведения вашего традиционного веб-приложения, поскольку они выполняют AJAX (фоновые HTTP-вызовы) к API. Мобильные телефоны также выполняют вызовы API, как и телевизоры, игровые приставки и устройства IoT. SAML SSO не особенно хорош в этом.

OAuth и API

Многое изменилось и в том, как мы создаем API. В 2005 году люди инвестировали в WS-* для создания веб-сервисов. Теперь большинство разработчиков перешли на REST и API без сохранения состояния. Вкратце REST — это HTTP-команды, передающие пакеты JSON по сети.

Разработчики создают множество API. Экономика API — это обычное модное слово, которое вы можете услышать сегодня в залах заседаний. Компании должны защищать свои REST API таким образом, чтобы многие устройства могли получить к ним доступ. В старые времена вы вводили каталог своего имени пользователя/пароля, и приложение входило в систему прямо от вашего имени. Это привело к проблеме делегированной авторизации.

«Как я могу разрешить приложению доступ к моим данным, не обязательно сообщая ему мой пароль?»

Если вы когда-нибудь видели один из приведенных ниже диалогов, мы говорим об этом. Это приложение спрашивает, может ли оно получить доступ к данным от вашего имени.

Это OAuth.

OAuth — это платформа делегированной авторизации для REST/API. Это позволяет приложениям получать ограниченный доступ (области) к данным пользователя, не раскрывая пароль пользователя. Он отделяет аутентификацию от авторизации и поддерживает несколько вариантов использования, относящихся к различным возможностям устройства. Он поддерживает межсерверные приложения, браузерные приложения, мобильные/собственные приложения и консоли/телевизоры.

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

Проще говоря, OAuth находится где:

1. Приложение запрашивает авторизацию у пользователя
2. Пользователь авторизует приложение и предоставляет подтверждение
3. Приложение предоставляет серверу подтверждение авторизации для получения токена
4. Токен ограничен доступом только к тому, что Пользователь авторизовал для конкретного приложения

Центральные компоненты OAuth

OAuth построен на следующих центральных компонентах:

• Область действия и согласие
• Актеры
• клиентов
• Жетоны
• Сервер авторизации
• Потоки

Области OAuth

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

Области отделяют решения политики авторизации от принудительного применения. Это первый ключевой аспект OAuth. Разрешения спереди и по центру. Они не скрыты за уровнем приложения, который вам нужно перепроектировать. Они часто перечислены в документации по API: вот области, которые требуются этому приложению.

Вы должны получить это согласие. Это называется доверять при первом использовании. Это довольно значительное изменение пользовательского опыта в Интернете. Большинство людей до OAuth просто привыкли к диалоговым окнам имени и пароля. Теперь у вас есть этот новый экран, и вам нужно научить пользователей им пользоваться. Переобучить интернет-пользователей сложно. Есть самые разные пользователи, от технически подкованных молодых людей до бабушек и дедушек, которые не знакомы с этим потоком. Это новая концепция в Интернете, которая сейчас находится в центре внимания. Теперь вы должны авторизоваться и принести согласие.

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

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

Субъекты OAuth

Субъекты в потоках OAuth следующие:

• Владелец ресурса : владеет данными на сервере ресурсов. Например, я являюсь владельцем ресурса своего профиля в Facebook.
• Сервер ресурсов : API, в котором хранятся данные, к которым приложение хочет получить доступ
• Клиент : приложение, которое хочет получить доступ к вашим данным
• Сервер авторизации : основной механизм OAuth

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

Клиенты могут быть публичными и конфиденциальными. Между ними есть существенное различие в номенклатуре OAuth. Конфиденциальным клиентам можно доверить хранение секрета. Они не работают на десктопе и не распространяются через магазин приложений. Люди не могут перепроектировать их и получить секретный ключ. Они работают в защищенной области, где конечные пользователи не могут получить к ним доступ.

Общедоступные клиенты — это браузеры, мобильные приложения и устройства IoT.

Регистрация клиента также является ключевым компонентом OAuth. Это похоже на DMV OAuth. Вам необходимо получить номерной знак для вашего приложения. Так логотип вашего приложения отображается в диалоговом окне авторизации.

Токены OAuth

Токены доступа — это токены, которые клиент использует для доступа к серверу ресурсов (API). Они должны быть недолговечными. Думайте о них в часах и минутах, а не в днях и месяцах. Вам не нужен конфиденциальный клиент, чтобы получить токен доступа. Вы можете получить токены доступа с публичными клиентами. Они предназначены для оптимизации проблем масштабирования Интернета. Поскольку эти токены могут быть недолговечными и масштабироваться, их нельзя отозвать, вам просто нужно подождать, пока истечет время их действия.

Другой токен — это токен обновления. Это намного долговечнее; дни, месяцы, годы. Это можно использовать для получения новых токенов. Чтобы получить токен обновления, приложениям обычно требуются конфиденциальные клиенты с проверкой подлинности.

Жетоны обновления могут быть отозваны. Отзывая доступ приложения к панели управления, вы убиваете его токен обновления. Это дает вам возможность заставить клиентов чередовать секреты. Что вы делаете, так это используете свой токен обновления, чтобы получить новые токены доступа, и токены доступа передаются по сети, чтобы задействовать все ресурсы API. Каждый раз, когда вы обновляете свой токен доступа, вы получаете новый токен с криптографической подписью. Ключевое вращение встроено в систему.

Спецификация OAuth не определяет, что такое токен. Он может быть в любом формате, который вы хотите. Однако обычно вы хотите, чтобы эти токены были веб-токенами JSON (стандарт). В двух словах, JWT (произносится как «йот») — это безопасный и надежный стандарт для аутентификации токенов. JWT позволяют подписывать информацию (называемую утверждениями) цифровой подписью и могут быть проверены позднее с помощью секретного ключа подписи. Чтобы узнать больше о JWT, см. Руководство для начинающих по JWT в Java.

Токены извлекаются из конечных точек на сервере авторизации. Двумя основными конечными точками являются конечная точка авторизации и конечная точка токена. Они разделены для разных вариантов использования. Конечная точка авторизации — это место, куда вы идете, чтобы получить согласие и авторизацию от пользователя. Это возвращает разрешение на авторизацию, в котором говорится, что пользователь дал на это согласие. Затем авторизация передается на конечную точку токена. Конечная точка токена обрабатывает грант и говорит: «Отлично, вот ваш токен обновления и ваш токен доступа».

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

Недостатком является то, что это вызывает много трений разработчиков. Одной из самых больших проблем OAuth для разработчиков является необходимость управлять токенами обновления. Вы навязываете управление состоянием каждому разработчику клиента. Вы получаете преимущества ротации ключей, но вы только что причинили много боли разработчикам. Вот почему разработчики любят ключи API. Они могут просто скопировать/вставить их, вставить в текстовый файл и покончить с ними. Ключи API очень удобны для разработчика, но очень плохи для безопасности.

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

Мы немного поговорили о типах клиентов, типах токенов и конечных точках сервера авторизации и о том, как мы можем передать это серверу ресурсов. Я упомянул два разных потока: получение авторизации и получение токенов. Это не должно происходить на одном и том же канале. Передний канал — это то, что проходит через браузер. Браузер перенаправил пользователя на сервер авторизации, пользователь дал согласие. Это происходит в браузере пользователя. Как только пользователь получает разрешение на авторизацию и передает его приложению, клиентскому приложению больше не нужно использовать браузер для выполнения потока OAuth для получения токенов.

Токены предназначены для использования клиентским приложением, чтобы оно могло получить доступ к ресурсам от вашего имени. Мы называем это обратным каналом. Обратный канал — это HTTP-вызов непосредственно из клиентского приложения на сервер ресурсов для обмена предоставления авторизации на токены. Эти каналы используются для разных потоков в зависимости от возможностей вашего устройства.

Например, Front Channel Flow, где вы авторизуетесь через пользовательский агент, может выглядеть следующим образом:

1. Владелец ресурса запускает процесс делегирования доступа к защищенному ресурсу
2. Клиент отправляет запрос на авторизацию с желаемыми областями через перенаправление браузера на конечную точку авторизации на сервере авторизации
3. Сервер авторизации возвращает диалоговое окно согласия, в котором говорится: «Разрешаете ли вы этому приложению доступ к этим областям?» Конечно, вам нужно будет пройти аутентификацию в приложении, поэтому, если вы не авторизованы на своем сервере ресурсов, оно попросит вас войти в систему. Если у вас уже есть кешированный файл cookie сеанса, вы просто увидите диалоговое окно согласия. Просмотрите диалоговое окно согласия и согласитесь.
4. Предоставление авторизации передается обратно в приложение через перенаправление браузера. Это все происходит на переднем канале.

В этом потоке также есть дисперсия, называемая неявным потоком. Мы вернемся к этому через минуту.

Так это выглядит на проводе.

ПОЛУЧИТЬ https://accounts.google.com/o/oauth3/auth?scope=gmail.insert gmail.send
&redirect_uri=https://app.example.com/oauth3/обратный вызов
&response_type=код&client_id=812741506391
&state=af0ifjsldkj
 

HTTP/1.1 302 Найдено
Расположение: https://app.example.com/oauth3/callback?
код = MsCeLvIaQm6bTrgtp7&state = af0ifjsldkj
 

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

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

Ниже показано, как это выглядит в необработанном HTTP.

POST /oauth3/v3/токен HTTP/1.1
Хост: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
код = MsCeLvIaQm6bTrgtp7 & client_id = 812741506391&client_secret={client_secret}&redirect_uri=https://app.example.com/oauth3/callback&grant_type=authorization_code
 

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Носитель",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}
 

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

 curl -H "Авторизация: предъявитель 2YotnFZFEjr1zCsicMWpAA" \
  https://www.googleapis.com/gmail/v1/users/1444587525/сообщения
 

Итак, теперь у вас есть передний канал, задний канал, разные конечные точки и разные клиенты. Вы должны смешивать и сочетать их для разных вариантов использования. Это повышает сложность OAuth и может привести к путанице.

Потоки OAuth

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

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

Золотым стандартом является Код авторизации Flow , также известный как 3 Legged, который использует как передний, так и задний канал. Это то, о чем мы говорили больше всего в этой статье. Поток переднего канала используется клиентским приложением для получения предоставления кода авторизации. Обратный канал используется клиентским приложением для обмена предоставления кода авторизации на маркер доступа (и, при необходимости, маркер обновления). Предполагается, что владелец ресурса и клиентское приложение находятся на разных устройствах. Это самый безопасный поток, потому что вы можете аутентифицировать клиента, чтобы получить разрешение на авторизацию, а токены никогда не передаются через пользовательский агент. Существуют не только неявные потоки и потоки кода авторизации, но и дополнительные потоки, которые вы можете выполнять с помощью OAuth. Опять же, OAuth — это скорее фреймворк.

Для сценариев «сервер-сервер» может потребоваться использовать поток учетных данных клиента . В этом сценарии клиентское приложение является конфиденциальным клиентом, который действует сам по себе, а не от имени пользователя. Это скорее сценарий типа сервисной учетной записи. Все, что вам нужно, это учетные данные клиента для выполнения всего потока. Это поток только обратного канала для получения токена доступа с использованием учетных данных клиента. Он поддерживает общие секреты или утверждения в качестве учетных данных клиента, подписанных симметричными или асимметричными ключами.

Алгоритмы с симметричным ключом — это криптографические алгоритмы, которые позволяют вам расшифровывать что угодно, если у вас есть пароль. Это часто встречается при защите файлов PDF или ZIP.

Криптография с открытым ключом или асимметричная криптография — это любая криптографическая система, использующая пары ключей: открытый ключ и закрытый ключ. Публичные ключи могут быть прочитаны кем угодно, закрытые ключи священны для владельца. Это позволяет защитить данные без необходимости делиться паролем.

Существует также устаревший режим под названием Поток пароля владельца ресурса . Это очень похоже на сценарий прямой аутентификации с использованием имени пользователя и пароля и не рекомендуется. Это устаревший тип гранта для собственных приложений имени пользователя и пароля, таких как настольные приложения. В этом потоке вы отправляете клиентскому приложению имя пользователя и пароль, и оно возвращает токен доступа с сервера авторизации. Обычно он не поддерживает токены обновления и предполагает, что владелец ресурса и общедоступный клиент находятся на одном устройстве. Когда у вас есть API, который хочет говорить только по OAuth, но вам нужно иметь дело с клиентами старой школы.

Более поздним дополнением к OAuth является поток утверждений , который аналогичен потоку учетных данных клиента. Это было добавлено, чтобы раскрыть идею федерации. Этот поток позволяет серверу авторизации доверять разрешениям на авторизацию от третьих сторон, таких как SAML IdP. Сервер авторизации доверяет поставщику удостоверений. Утверждение используется для получения токена доступа из конечной точки токена. Это отлично подходит для компаний, которые инвестировали в SAML или технологии, связанные с SAML, и позволяют им интегрироваться с OAuth. Поскольку утверждения SAML недолговечны, в этом потоке нет токенов обновления, и вы должны получать токены доступа каждый раз, когда срок действия утверждения истекает.

Не входит в спецификацию OAuth, это Device Flow . Там нет веб-браузера, просто контроллер для чего-то вроде телевизора. Код пользователя возвращается из запроса на авторизацию, который необходимо активировать, посетив URL-адрес на устройстве с браузером для авторизации. Поток обратного канала используется клиентским приложением для запроса утверждения авторизации для маркера доступа и, при необходимости, маркера обновления. Также популярен для клиентов CLI.

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

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

Безопасность и предприятие

С OAuth существует большая поверхность. С неявным потоком существует множество редиректов и много места для ошибок. Было много людей, пытающихся использовать OAuth между приложениями, и это легко сделать, если вы не следуете рекомендациям Web Security 101. Например:

• Всегда используйте токен CSRF с параметром состояния для обеспечения целостности потока
• Всегда вносить в белый список URI перенаправления, чтобы обеспечить правильную проверку URI
• Привязать одного и того же клиента к грантам авторизации и запросам токенов с идентификатором клиента
• Для конфиденциальных клиентов убедитесь, что секреты клиентов не утекли. Не добавляйте секрет клиента в свое приложение, которое распространяется через App Store!

Самая большая жалоба на OAuth исходит от сотрудников службы безопасности. Это касается токенов Bearer и того, что их можно передавать так же, как сеансовые файлы cookie. Вы можете передать его всем, и все готово, он не привязан криптографически к пользователю. Использование JWT помогает, потому что их нельзя подделать. Однако, в конце концов, JWT — это просто строка символов, которую можно легко скопировать и использовать в Заголовок авторизации .

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

OAuth отделяет ваши решения политики авторизации от аутентификации. Он обеспечивает правильное сочетание мелкозернистой и крупнозернистой авторизации. Он может заменить традиционные политики управления веб-доступом (WAM). Это также отлично подходит для ограничения и отзыва разрешений при создании приложений, которые могут получить доступ к определенным API. Это гарантирует, что только управляемые и/или совместимые устройства могут получить доступ к определенным API. Он имеет глубокую интеграцию с рабочими процессами деинициализации удостоверений для отзыва всех токенов у пользователя или устройства. Наконец, он поддерживает федерацию с поставщиком удостоверений.

OAuth не является протоколом аутентификации

Подводя итог некоторым заблуждениям относительно OAuth 2.0: он не имеет обратной совместимости с OAuth 1.0. Он заменяет подписи на HTTPS для всех коммуникаций. Когда люди сегодня говорят об OAuth, они имеют в виду OAuth 2.0.

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

OAuth 2.0 не является протоколом аутентификации. Об этом даже говорится в его документации.

Все это время мы говорили о делегированной авторизации. Речь идет не об аутентификации пользователя, и это ключевой момент. Один только OAuth 2.0 абсолютно ничего не говорит о пользователе. У вас просто есть токен для доступа к ресурсу.

За последние несколько лет в OAuth произошло огромное количество дополнений. Они усложняют OAuth для выполнения различных корпоративных сценариев. Например, JWT можно использовать в качестве интероперабельных токенов, которые можно подписывать и шифровать.

Псевдо-аутентификация с помощью OAuth 2.0

Вход с помощью OAuth стал известен благодаря Facebook Connect и Twitter. В этом потоке клиент получает доступ к конечной точке /me с маркером доступа. Все, что он говорит, это то, что клиент имеет доступ к ресурсу с токеном. Люди изобрели эту фальшивую конечную точку как способ вернуть профиль пользователя с токеном доступа. Это нестандартный способ получения информации о пользователе. В стандартах нет ничего, что говорило бы о том, что каждый должен реализовать эту конечную точку. Токены доступа должны быть непрозрачными. Они предназначены для API, они не предназначены для хранения информации о пользователе.

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

Введите OpenID Connect

Чтобы решить проблему псевдоаутентификации, лучшие части OAuth 2.0, Facebook Connect и SAML 2.0 были объединены для создания OpenID Connect. OpenID Connect (OIDC) расширяет OAuth 2.0 новым подписанным id_token для клиента и конечная точка UserInfo для получения атрибутов пользователя. В отличие от SAML, OIDC предоставляет стандартный набор областей и утверждений для удостоверений. Примеры: профиль , электронная почта , адрес и телефон .

OIDC был создан для масштабирования в Интернете за счет полной динамики. Больше не нужно загружать метаданные и федерацию, как того требует SAML. Есть встроенная регистрация, обнаружение и метаданные для динамических федераций. Вы можете ввести свой адрес электронной почты, затем он динамически обнаружит вашего поставщика OIDC, динамически загрузит метаданные, динамически узнает, какие сертификаты он собирается использовать, и разрешит BYOI (Bring Your Own Identity). Он поддерживает высокие уровни надежности и основные варианты использования SAML для предприятий.

OIDC прославили Google и Microsoft, которые первыми внедрили эту технологию. Okta также вложила большие средства в OIDC.

Все изменения в первоначальном запросе заключаются в том, что он содержит стандартные области видимости (например, openid и электронная почта ):

ПОЛУЧИТЬ https://accounts.google.com/o/oauth3/auth?
объем =  электронная почта openid  &
redirect_uri=https://app. example.com/oauth3/callback&
response_type=код&
client_id=812741506391&
состояние = af0ifjsldkj
 

HTTP/1.1 302 Найдено
Расположение: https://app.example.com/oauth3/callback?
код = MsCeLvIaQm6bTrgtp7&state = af0ifjsldkj
 

И ответ на предоставление авторизации для токенов содержит токен ID.

POST /oauth3/v3/токен HTTP/1.1
Хост: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
код=MsCeLvIaQm6bTrgtp7&client_id=812741506391&
  client_secret={client_secret}&
  redirect_uri=https://app.example.com/oauth3/callback&
  grant_type = код_авторизации
 

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Носитель",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
    "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ. .." 
}
 

Вы можете видеть, что это красиво наложено поверх OAuth, чтобы вернуть токен идентификатора в виде структурированного токена. Идентификационный токен — это веб-токен JSON (JWT). JWT (также известный как «jot») намного меньше, чем гигантское утверждение SAML на основе XML, и его можно эффективно передавать между различными устройствами. JWT состоит из трех частей: заголовка, тела и подписи. В шапке написано, по какому алгоритму его подписали, претензии в теле, а в подписи подписано.

Процесс Open ID Connect включает следующие шаги:

1. Обнаружение метаданных OIDC
2. Выполните поток OAuth для получения маркера идентификатора и маркера доступа
3. Получить ключи подписи JWT и при необходимости динамически зарегистрировать клиентское приложение
4. Проверка токена JWT ID локально на основе встроенных дат и подписи
5. Получите дополнительные атрибуты пользователя по мере необходимости с помощью токена доступа

OAuth + Okta

Okta наиболее известна своими службами единого входа, которые позволяют беспрепятственно проходить аутентификацию в приложениях, которые вы используете ежедневно. Но знаете ли вы, что у Okta также есть отличная платформа для разработчиков? Безопасный единый вход часто использует SAML в качестве предпочтительного протокола, но Okta также предоставляет несколько других опций, включая виджет входа, Auth SDK (библиотека на основе JavaScript), вход через социальные сети и API аутентификации для любого клиента. Если вам интересно узнать об Okta прямо из первоисточника, вам стоит посетить Oktane17 в конце августа. Есть трек, посвященный разработке приложений.

См. API OIDC/OAuth 2.0 Okta для получения конкретной информации о том, как мы поддерживаем OAuth.

SAML реализован компанией Okta с ее чиклетами SSO. Если вы являетесь клиентом Okta, как и я, вы, вероятно, взаимодействуете с большинством приложений, используя что-то вроде https://okta.okta.com/app/UserHome. При нажатии на чиклет отправляем сообщение, подписываем ассерт, внутри ассертии написано, кто пользователь, и что пришло от Окты. Поставьте на нем цифровую подпись, и все готово.

Если вы предпочитаете посмотреть видео, чтобы узнать об OAuth, посмотрите презентацию ниже от Нейта Барбеттини, менеджера по продукту в Okta.

Обзор OAuth 2.0

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

OAuth имеет очень большую поверхность безопасности. Обязательно используйте безопасный инструментарий и проверяйте все входные данные!

OAuth не является протоколом аутентификации. OpenID Connect расширяет возможности OAuth 2.0 для сценариев аутентификации и часто называется «SAML с фигурными скобками». Если вы хотите еще глубже погрузиться в OAuth 2.0, я рекомендую вам зайти на OAuth.com, попробовать SDK Okta Auth и опробовать потоки OAuth для себя.

Если вы хотите узнать больше об OAuth и OIDC, мы предлагаем следующие сообщения:

• Что такое тип гранта кода авторизации OAuth 2.0?
• Что такое неявный тип предоставления OAuth 2.0?
• Что такое тип предоставления пароля OAuth 2.0?
• Неявный поток OAuth 2.0 мертв?
• Идентификация, претензии и токены — учебник по OpenID Connect, часть 1 из 3
• OIDC в ​​действии — введение в OpenID Connect, часть 2 из 3
• Что в токене? – Учебник OpenID Connect, часть 3 из 3

Если вы так же, как и мы, увлечены OAuth 2.0 и OIDC, подпишитесь на нас в Twitter или посетите наш новый сайт по безопасности, где мы публикуем подробные статьи по вопросам безопасности.

Использование OAuth 2.0 для доступа к API Google | Google Identity

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

Для начала получите учетные данные клиента OAuth 2.0 из Консоль Google API. Затем ваше клиентское приложение запрашивает токен доступа с сервера авторизации Google, извлекает токен из ответа и отправляет токен в API Google, к которому вы хотите получить доступ. Для интерактивной демонстрации использования OAuth 2.0 с Google (включая возможность использования собственных учетных данных клиента), поэкспериментируйте с OAuth 2.0 Детская площадка.

На этой странице представлен обзор сценариев авторизации OAuth 2. 0, поддерживаемых Google, и предоставляет ссылки на более подробный контент. Подробнее об использовании OAuth 2.0 для аутентификации, см. OpenID Connect.

Основные шаги

Все приложения следуют основному шаблону при доступе к API Google с использованием OAuth 2.0. В высокий уровень, вы выполняете пять шагов:

1. Получите учетные данные OAuth 2.0 из Google API Console.

Посетите Google API Console для получения учетных данных OAuth 2. 0, таких как клиент Идентификатор и секрет клиента, которые известны как Google, так и вашему приложению. Набор значений варьируется в зависимости от того, какой тип приложения вы создаете. Например, JavaScript приложение не требует секрета, но приложение веб-сервера требует.

2. Получите токен доступа с сервера авторизации Google.

Прежде чем ваше приложение сможет получить доступ к личным данным с помощью Google API, оно должно получить токен доступа, который предоставляет доступ к этому API. Один токен доступа может предоставлять различные степени доступа к нескольким API. Переменный параметр с именем Scope управляет набором ресурсов и операций, разрешенных токеном доступа. Во время запроса токена доступа ваше приложение отправляет одно или несколько значений в область действия параметр.

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

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

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

Как правило, рекомендуется запрашивать области постепенно, в то время, когда требуется доступ, а не впереди. Например, приложение, которое хочет поддерживать сохранение события в календаре. не следует запрашивать доступ к Календарю Google, пока пользователь не нажмет кнопку «Добавить в Календарь»; видеть Инкрементальная авторизация.

3. Изучите области доступа, предоставленные пользователем.

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

Объем, включенный в ваш запрос, может не соответствовать объему, указанному в вашем ответе, даже если пользователь предоставил все запрошенные области. Обратитесь к документации для каждого API Google для области, необходимые для доступа. API может сопоставлять несколько строковых значений области действия с одним область доступа, возвращающая одну и ту же строку области для всех значений, разрешенных в запросе. Пример: Google People API может возвращать область https://www.googleapis.com/auth/contacts , когда приложение запросило авторизацию пользователя область https://www.google.com/m8/feeds/; метод Google People API человек.updateКонтакт требуется предоставленная область https://www.googleapis.com/auth/contacts .

4. Отправьте токен доступа в API.

После того, как приложение получает токен доступа, оно отправляет токен в Google API в Заголовок HTTP-запроса авторизации. Можно отправлять токены в качестве параметров строки запроса URI, но мы не рекомендуем это делать. потому что параметры URI могут оказаться в файлах журналов, которые не являются полностью безопасными. Кроме того, это хорошая практика REST, позволяющая избежать создания ненужных имен параметров URI.

Токены доступа действительны только для набора операций и ресурсов, описанных в область запроса токена. Например, если токен доступа выдан для Google Calendar API, он не предоставляет доступ к Google Contacts API. Вы можете, однако, несколько раз отправьте этот токен доступа в Google Calendar API для выполнения аналогичных операций.

5. При необходимости обновите токен доступа.

Токены доступа имеют ограниченный срок действия. Если вашему приложению требуется доступ к Google API по истечении срока действия одного токена доступа он может получить токен обновления. Обновление token позволяет вашему приложению получать новые токены доступа.

Сценарии

Приложения веб-сервера

Конечная точка Google OAuth 2.0 поддерживает приложения веб-сервера, использующие языки и фреймворков, таких как PHP, Java, Python, Ruby и ASP.NET.

Последовательность авторизации начинается, когда ваше приложение перенаправляет браузер на Google URL-адрес; URL-адрес включает параметры запроса, которые указывают тип запрашиваемого доступа. Google обрабатывает аутентификацию пользователя, выбор сеанса и согласие пользователя. Результат код авторизации, который приложение может обменять на токен доступа и обновление токен.

Приложение должно сохранить токен обновления для будущего использования и использовать токен доступа для получить доступ к Google API. По истечении срока действия токена доступа приложение использует токен обновления. для получения нового.

Дополнительные сведения см. в разделе Использование OAuth 2.0 для Интернета. Серверные приложения.

Установленные приложения

Конечная точка Google OAuth 2.0 поддерживает приложения, установленные на таких устройствах, как компьютеры, мобильные устройства и планшеты. Когда вы создаете идентификатор клиента через Консоль Google API, укажите, что это установленное приложение, затем выберите Android, приложение Chrome, iOS, Универсальная платформа Windows (UWP) или настольное приложение в качестве типа приложения.

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

Последовательность авторизации начинается, когда ваше приложение перенаправляет браузер на Google URL-адрес; URL-адрес включает параметры запроса, которые указывают тип запрашиваемого доступа. Google обрабатывает аутентификацию пользователя, выбор сеанса и согласие пользователя. Результат код авторизации, который приложение может обменять на токен доступа и обновление токен.

Приложение должно сохранить токен обновления для будущего использования и использовать токен доступа для получить доступ к Google API. По истечении срока действия токена доступа приложение использует токен обновления. для получения нового.

Подробнее см. Использование OAuth 2. 0 для установленных приложений.

Клиентские (JavaScript) приложения

Конечная точка Google OAuth 2.0 поддерживает приложения JavaScript, которые запускаются в браузере.

Последовательность авторизации начинается, когда ваше приложение перенаправляет браузер на Google URL-адрес; URL-адрес включает параметры запроса, которые указывают тип запрашиваемого доступа. Google обрабатывает аутентификацию пользователя, выбор сеанса и согласие пользователя.

Результатом является токен доступа, который клиент должен проверить, прежде чем включать его в Запрос API Google. По истечении срока действия токена приложение повторяет процесс.

Подробнее см. Использование OAuth 2.0 для клиентских приложений.

Приложения на устройствах с ограниченным вводом

Конечная точка Google OAuth 2. 0 поддерживает приложения, работающие на устройствах с ограниченным вводом, таких как как игровые приставки, видеокамеры и принтеры.

Последовательность авторизации начинается с того, что приложение делает запрос веб-службы к URL-адрес Google для кода авторизации. Ответ содержит несколько параметров, в том числе URL и код, который приложение показывает пользователю.

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

Тем временем приложение опрашивает URL-адрес Google с заданным интервалом. После пользователя одобряет доступ, ответ от сервера Google содержит токен доступа и обновление токен. Приложение должно хранить токен обновления для будущего использования и использовать доступ токен для доступа к Google API. По истечении срока действия токена доступа приложение использует обновить токен, чтобы получить новый.

Дополнительные сведения см. в разделе Использование OAuth 2.0. для устройств.

Сервисные аккаунты

Google API, такие как Prediction API и Google Cloud Storage, могут действовать от имени вашего приложение без доступа к пользовательской информации. В этих ситуациях ваше приложение нуждается чтобы подтвердить свою личность перед API, но согласие пользователя не требуется. Точно так же в В корпоративных сценариях ваше приложение может запросить делегированный доступ к некоторым ресурсам.

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

Учетные данные служебной учетной записи, которые вы получаете от Google API Console, включите сгенерированный уникальный адрес электронной почты, идентификатор клиента и как минимум одна пара открытого/закрытого ключа. Вы используете идентификатор клиента и один частный key для создания подписанного JWT и создания запроса маркера доступа в соответствующем формате. Затем ваше приложение отправляет запрос токена на сервер авторизации Google OAuth 2.0, который возвращает токен доступа. Приложение использует токен для доступа к Google API. Когда токен истекает, приложение повторяет процесс.

Подробнее см. документация по служебной учетной записи.

Размер токена

Токены могут различаться по размеру до следующих пределов:

• Коды авторизации: 256 байт
• Маркеры доступа: 2048 байт
• Токены обновления: 512 байт

Токены доступа, возвращенные Google Cloud API службы токенов безопасности структурированы аналогично токенам доступа Google API OAuth 2.0, но имеют другой размер токена. пределы. Подробнее см. Документация по API.

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

Срок действия маркера обновления

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

• Пользователь имеет отозвал доступ вашего приложения.
• Токен обновления не использовался в течение шести месяцев.
• Пользователь изменил пароли, а токен обновления содержит области действия Gmail.
• Учетная запись пользователя превысила максимальное количество предоставленных (действующих) токенов обновления.
• Пользователь принадлежит к организации Google Cloud Platform, в которой действуют политики управления сеансами.

Проект Google Cloud Platform с экраном согласия OAuth, настроенным для внешнего тип пользователя и статус публикации «Тестирование» выдается токен обновления, срок действия которого истекает через 7 дней.

В настоящее время существует ограничение в 100 токенов обновления на аккаунт Google для каждого идентификатора клиента OAuth 2.0. Если предел достигнут, создание нового токена обновления автоматически делает недействительным самый старый обновить токен без предупреждения. Это ограничение не распространяется на сервисные счета.

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

Если вам нужно авторизовать несколько программ, компьютеров или устройств, ограничить количество клиентов, которые вы авторизуете для каждой учетной записи Google, до 15 или 20. Если вы являетесь администратор Google Workspace, вы можете создать дополнительных пользователей с правами администратора и использовать их для авторизации часть клиентов.

Работа с политиками управления сеансами для организаций Google Cloud Platform (GCP)

Администраторам организаций GCP может потребоваться частая повторная аутентификация пользователей во время они получают доступ к ресурсам GCP, используя Контроль сеанса Google Cloud особенность. Эта политика влияет на доступ к Google Cloud Console, Google Cloud SDK (также известный как gcloud CLI) и любое стороннее приложение OAuth, для которого требуется область Cloud Platform. Если пользователь имеет политику управления сеансом, то по истечении продолжительности сеанса ваш Вызовы API завершатся ошибкой, аналогичной тому, что произойдет, если маркер обновления будет отозван. вызов завершится с ошибкой типа неверный_токен ; тип подошибки может быть используется для различения маркера отзыва и сбоя из-за политики управления сеансом. В качестве продолжительность сеанса может быть очень ограничена (от 1 часа до 24 часов), этот сценарий должен корректно обрабатывается перезапуском сеанса аутентификации.

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

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

Клиентские библиотеки

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

• Клиентская библиотека Google API для Java
• Клиентская библиотека Google API для Python
• Клиентская библиотека Google API для Go
• Клиентская библиотека Google API для .NET
• Клиентская библиотека Google API для Ruby
• Клиентская библиотека Google API для PHP
• Клиентская библиотека Google API для JavaScript
• GTMAppAuth — клиентская библиотека OAuth для Mac и iOS

Что такое OAuth? Как работает открытая структура авторизации

Функция

OAuth позволяет веб-сайтам и службам обмениваться активами между пользователями.

Роджер А. Граймс и Джош Фрулингер

ОГО |

С момента появления распределенных сетей персональных компьютеров одной из самых сложных задач в области компьютерной безопасности было обеспечение беспрепятственного доступа с единым входом (SSO) между несколькими компьютерами, каждый из которых требует несвязанных учетных записей для доступа к своим службам. и содержание. Хотя это еще не полностью реализовано во всем Интернете, теперь можно получить доступ к множеству совершенно не связанных между собой веб-сайтов с помощью одного физического входа. Вы можете использовать свой пароль, телефон, цифровой сертификат, биометрическую идентификацию, двухфакторную аутентификацию (2FA) или многофакторную аутентификацию (MFA) SSO для входа в одно место, и вам не нужно вводить другие учетные данные для доступа в течение всего дня. куча других. Во многом благодаря OAuth.

Определение OAuth

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

История OAuth

Созданный и активно поддерживаемый с самого начала Twitter, Google и другими компаниями, OAuth был выпущен как открытый стандарт в 2010 году как RFC 5849., и быстро получил широкое распространение. В течение следующих двух лет он был существенно переработан, и в 2012 году была выпущена версия 2.0 OAuth под номером RFC 6749. Несмотря на то, что версия 2.0 подверглась широкой критике по нескольким причинам, описанным ниже, она приобрела еще большую популярность. Сегодня вы можете добавить Amazon, Facebook, Instagram, LinkedIn, Microsoft, Netflix, Paypal и список других интернет-пользователей в качестве пользователей.

Примеры OAuth

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

Другим распространенным примером сценария OAuth может быть отправка пользователем хранящихся в облаке файлов другому пользователю по электронной почте, когда облачное хранилище и системы электронной почты в остальном не связаны друг с другом, кроме поддержки платформы OAuth (например, Google Gmail и Microsoft OneDrive). Когда конечный пользователь прикрепляет файлы к своей электронной почте и просматривает, чтобы выбрать файлы для прикрепления, OAuth можно использовать за кулисами, чтобы позволить системе электронной почты беспрепятственно аутентифицировать и просматривать защищенные файлы, не требуя повторного входа в хранилище файлов. система. Другой пример, приведенный в RFC OAuth 2.0, — это конечный пользователь, использующий стороннюю службу печати для печати файлов изображений, хранящихся на несвязанном веб-сервере.

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

Объяснение OAuth

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

Также полезно помнить, что OAuth предназначен, в частности, для авторизации, а не для аутентификации напрямую. Аутентификация — это процесс подтверждения пользователем/субъектом своего права на представленную личность путем предоставления пароля или какого-либо другого уникального принадлежащего или представленного фактора. Авторизация — это процесс предоставления субъекту доступа к ресурсам после успешной аутентификации, часто в другом месте. Многие люди думают, что OAuth означает открытую аутентификацию, но полезнее понять это, рассматривая его как открытую AUTHorization.

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

Кроме того, OAuth 2.0 — это платформа, а не протокол (как и версия 1.0). Это было бы похоже на то, как все производители автомобилей пришли бы к соглашению о том, как парковщики будут автоматически запрашивать, получать и использовать ключи парковщика, и как в целом будут выглядеть эти ключи парковщика. Что могут делать ключи камердинера по сравнению с полнофункциональными клавишами, зависит от каждого производителя автомобилей. Как и в реальной жизни, парковщикам и владельцам автомобилей не нужно заботиться о том, как все это работает. Они просто хотят, чтобы все работало максимально гладко, когда они передают ключ.

Как работает OAuth

Предположим, что пользователь уже вошел на один веб-сайт или службу (OAuth работает только с использованием HTTPS). Затем пользователь инициирует функцию/транзакцию, которая требует доступа к другому несвязанному сайту или сервису. Происходит следующее (значительно упрощенное):

1. Первый веб-сайт подключается ко второму веб-сайту от имени пользователя, используя OAuth, предоставляя проверенную личность пользователя.
2. Второй сайт создает одноразовый токен и одноразовый секрет, уникальный для транзакции и участвующих сторон.
3. Первый сайт передает этот токен и секрет клиентскому программному обеспечению инициирующего пользователя.
4. Программное обеспечение клиента предоставляет токен запроса и секрет своему поставщику авторизации (который может быть или не быть вторым сайтом).
5. Если клиент еще не прошел проверку подлинности у поставщика авторизации, ему может быть предложено пройти проверку подлинности. После аутентификации клиенту предлагается подтвердить транзакцию авторизации на втором веб-сайте.
6. Пользователь утверждает (или его программное обеспечение автоматически утверждает) определенный тип транзакции на первом веб-сайте.
7. Пользователю предоставляется утвержденный токен доступа (обратите внимание, что это больше не токен запроса).
8. Пользователь предоставляет одобренный токен доступа к первому веб-сайту.
9. Первый веб-сайт предоставляет маркер доступа второму веб-сайту в качестве доказательства аутентификации от имени пользователя.
10. Второй веб-сайт позволяет первому веб-сайту получить доступ к своему сайту от имени пользователя.
11. Пользователь видит успешно завершенную транзакцию.
12. OAuth — не первая система аутентификации/авторизации, работающая таким образом от имени конечного пользователя. На самом деле многие системы аутентификации, особенно Kerberos, работают аналогичным образом. Что особенного в OAuth, так это его способность работать в Интернете и его широкое распространение. Это удалось с темпами принятия там, где предыдущие попытки не увенчались успехом (по разным причинам).

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

OAuth против OpenID

Есть несколько других технологий безопасности, о которых вы могли слышать в том же контексте, что и OAuth, и одна из них — OpenID. На базовом уровне разницу между ними легко понять. Помните, мы говорили выше, что auth в OAuth означает авторизацию, а не аутентификацию? Что ж, OpenID — это в отношении аутентификации: как лаконично выразился комментатор StackOverflow: «OpenID предназначен для людей, регистрирующихся на машинах, OAuth — для машин, регистрирующихся на машинах от имени людей».

OpenID зародился в 2005 году как средство для входа в популярный в то время блог-сайт LiveJournal, но быстро распространился на другие сайты. Идея на заре Web 2.0 заключалась в том, что вместо нескольких входов в систему для нескольких веб-сайтов OpenID будет служить единым входом, подтверждающим личность пользователей. Но на практике OpenID было трудно внедрить на стороне разработчиков, и он никогда не становился таким привлекательным для пользователей, тем более что в этой сфере существовала конкуренция. К 2011 году OpenID стала популярной и, Wired заявил, что «основная причина, по которой никто не использует OpenID, заключается в том, что Facebook Connect делает то же самое и делает это лучше. ОпенИД.» (Facebook Connect тоже не стал мировым лидером, но, по крайней мере, люди знали, что такое Facebook.)

Однако это еще не конец истории. В 2014 году был выпущен OpenID Connect, который заново изобрел OpenID в качестве уровня аутентификации для OAuth. В этом пространстве OpenID нашел свою нишу, и теперь эти две технологии дополняют друг друга во многих реализациях.

OAuth против SAML

Язык разметки утверждений безопасности, или SAML , — это еще одна технология, о которой вы услышите на одном дыхании с OAuth. Строго говоря, название SAML относится к вариантному языку XML, но этот термин может также охватывать различные протокольные сообщения и профили, составляющие часть открытого стандарта SAML. SAML описывает структуру, которая позволяет одному компьютеру выполнять и аутентификацию и авторизацию от имени одного или нескольких других компьютеров, в отличие от OAuth, который требует дополнительного уровня, такого как OpenID Connect, для выполнения аутентификации. SAML может самостоятельно обеспечивать функциональность единого входа.

SAML старше OAuth, и действительно, одним из движущих факторов создания OAuth было то, что протоколы XML, такие как SAML, начали выходить из моды; OAuth использует более легкий JSON для кодирования данных и, таким образом, лучше поддерживает мобильные устройства. На практике SAML чаще используется для корпоративных приложений — например, Salesforce использует его для единого входа — тогда как OAuth чаще используется в открытом Интернете.

OAuth3

Не существует идеальных универсальных стандартов аутентификации в Интернете. OAuth особенно оклеветан из-за радикальных изменений между версиями 1.0 и 2.0. Во многих отношениях OAuth3 равен 9.0379 менее безопасный, более сложный и менее предписывающий, чем версия 1.0. Создатели версии 2.0 сосредоточились на том, чтобы сделать OAuth более совместимым и гибким между сайтами и устройствами. Они также представили концепцию истечения срока действия токена, которой не было в версии 1.0. Независимо от намерений, многие из первоначальных основателей и сторонников опустили руки и не поддержали версию 2.0.

Изменения настолько значительны, что версия 2.0 не совместима с версией 1.0, и даже разные реализации версии 2.0 могут несовместимо друг с другом. Однако ничто не мешает веб-сайту поддерживать как 1. 0, так и 2.0, хотя создатели 2.0 выпустили его с намерением полностью заменить всеми веб-сайтами версию 1.0.

Одним из самых больших критических замечаний по поводу OAuth 2.0 является то, что стандарт намеренно не определяет и не поддерживает напрямую шифрование, подпись, проверку клиента или привязку канала (привязку определенного сеанса или транзакции к определенному клиенту и серверу). Вместо этого OAuth ожидает, что разработчики будут использовать внешний протокол защиты, такой как Transport Layer Security (TLS), для предоставления этих функций.

Безопасен ли OAuth?

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

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

Это не просто теоретическая угроза. Во втором квартале 2017 года был успешно фишингован миллион аккаунтов Google. Защита заключается в том, чтобы пользователи могли убедиться, что они вводят свои учетные данные в домен законного второго веб-сайта, если запрашиваются учетные данные, и избегать туманных первых веб-сайтов. Не существует абсолютно безопасной, общепризнанной системы единого входа, которая работала бы на всех веб-сайтах, но с OAuth мы приближаемся к этому.

Подробнее о едином входе и управлении идентификацией:

• Что такое управление идентификацией? Его определение, использование и решения
• Лучший совет по управлению идентификацией прямо сейчас
• Что такое SAML, для чего он используется и как он работает?

Связанный:

• Аутентификация
• Безопасность
• Интернет

Copyright © 2019 IDG Communications, Inc.

7 горячих тенденций кибербезопасности (и 2 уходят в тень)

Что такое OAuth? Определение и принцип работы

Блог о внутренней безопасности / Безопасность данных

Роб Соберс

|

5 минут чтения

|

Последнее обновление 5 апреля 2012 г.

Мы говорили о разглашении ваших паролей и о том, что вы никогда не должны этого делать. Когда веб-сайт хочет использовать услуги другого — например, Bitly для публикации в вашей ленте Twitter — вместо того, чтобы просить вас поделиться своим паролем, он должен вместо этого использовать протокол под названием OAuth.

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

Что такое OAuth?

OAuth — это протокол или инфраструктура авторизации открытого стандарта, которая предоставляет приложениям возможность «безопасного назначенного доступа». Например, вы можете сообщить Facebook, что ESPN.com может получать доступ к вашему профилю или публиковать обновления в вашей хронике, не сообщая ESPN свой пароль Facebook. Это значительно снижает риск: в случае взлома ESPN ваш пароль Facebook останется в безопасности.

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

SAML и OAuth

SAML (язык разметки подтверждения безопасности) — это альтернативный стандарт федеративной проверки подлинности, который многие предприятия используют для единого входа (SSO). SAML позволяет предприятиям отслеживать, кто имеет доступ к корпоративным ресурсам.

Существует много различий между SAML и OAuth. SAML использует XML для передачи сообщений, а OAuth использует JSON. OAuth упрощает работу с мобильными устройствами, а SAML ориентирован на корпоративную безопасность. Этот последний пункт является ключевым отличием: OAuth широко использует вызовы API, поэтому мобильные приложения, современные веб-приложения, игровые консоли и устройства Интернета вещей (IoT) считают OAuth более удобным для пользователя. SAML, с другой стороны, размещает в браузере файл cookie сеанса, который позволяет пользователю получить доступ к определенным веб-страницам — отлично подходит для недолгих рабочих дней, но не так хорош, когда приходится каждый день входить в свой термостат.

Beyond SSO: Singular Security от Varonis

Oauth/SAML помогает определить, кто имеет доступ к вашей сети, но вам нужен Varonis, чтобы получить полное представление о том, что они делают и к каким конфиденциальным данным получают доступ.

Узнайте, как Varonis помогает завершить авторизацию -> доступ к изображению сейчас:

Примеры OAuth

Самый простой пример OAuth в действии — это один веб-сайт, говорящий: «Эй, не хотите ли вы войти на наш веб-сайт, используя логин другого веб-сайта?» В этом сценарии единственное, что нужно сделать первому веб-сайту — назовем этот веб-сайт 9-м.0379 потребитель — хочет знать, что пользователь является одним и тем же пользователем на обоих веб-сайтах и ​​успешно вошел в систему поставщика услуг — это сайт, на который первоначально вошел пользователь, а не потребитель.

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

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

Объяснение OAuth

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

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

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

Как работает OAuth

В транзакции OAuth участвуют 3 основных участника: пользователь, потребитель и поставщик услуг. Этот триумвират ласково называют любовным треугольником OAuth.

В нашем примере Джо — пользователь, Bitly — потребитель, а Twitter — предоставляемая служба, которая контролирует защищенный ресурс Джо (его поток в Твиттере). Джо хотел бы, чтобы Bitly мог публиковать сокращенные ссылки на его поток. Вот как это работает:

Шаг 1. Пользователь демонстрирует намерение

• Джо (пользователь): «Привет, Битли, я бы хотел, чтобы ты мог публиковать ссылки прямо на мой поток в Твиттере».
• Bitly (Потребитель): «Отлично! Позвольте мне спросить разрешения».

Шаг 2 — Потребитель получает разрешение

• Bitly: «У меня есть пользователь, который хотел бы, чтобы я разместил пост в его потоке. Могу ли я получить токен запроса?»
• Твиттер (поставщик услуг): «Конечно. Вот знак и секрет.

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

Шаг 3. Пользователь перенаправляется к поставщику услуг

• Битовый: «Хорошо, Джо. Я отправляю вас в Twitter, чтобы вы могли одобрить. Возьми этот жетон с собой».
• Джо: «ОК!»

— Битли направляет Джо в Твиттер для авторизации >

Это самое страшное. Если бы Bitly была супер-теневой Evil Co., она могла бы открыть окно, похожее на Twitter, но на самом деле это фишинг для вашего имени пользователя и пароля. Всегда проверяйте, что URL-адрес, на который вы перешли, действительно принадлежит поставщику услуг (в данном случае Twitter).

Шаг 4. Пользователь дает разрешение

• Джо: «Twitter, я хочу авторизовать этот токен запроса, который дал мне Bitly».
• Твиттер: «Хорошо, просто чтобы быть уверенным, вы хотите разрешить Bitly делать X, Y и Z с вашей учетной записью Twitter?»
• Джо: «Да!»
• Twitter: «Хорошо, вы можете вернуться в Bitly и сказать им, что у них есть разрешение на использование токена запроса».

Twitter помечает токен запроса как «годный», поэтому, когда потребитель запрашивает доступ, он будет принят (при условии, что он подписан с использованием их общего секрета).

Шаг 5 — Потребитель получает маркер доступа

• Bitly: «Twitter, могу ли я обменять этот токен запроса на токен доступа?»
• Twitter: «Конечно. Вот ваш токен доступа и секрет».

Шаг 6 — Потребитель получает доступ к защищенному ресурсу

• Bitly: «Я хотел бы опубликовать эту ссылку на стрим Джо. Вот мой токен доступа!»
• Twitter: «Готово!»

В нашем сценарии Джо никогда не приходилось делиться своими учетными данными Twitter с Bitly. Он просто безопасно делегировал доступ с помощью OAuth. В любое время Джо может войти в Твиттер, просмотреть предоставленный им доступ и отозвать токены для определенных приложений, не затрагивая других. OAuth также позволяет детализировать уровни разрешений. Вы можете предоставить Bitly право публиковать сообщения в своей учетной записи Twitter, но ограничить LinkedIn доступом только для чтения.

Сравнение OAuth 1.0 и OAuth 2.0

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

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

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

Другие ресурсы

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

Если вы хотите глубже погрузиться в механику OAuth, вот несколько полезных ссылок:

• http://marktrapp.com/blog/2009/09/17/oauth-думми
• http://stackoverflow.com/questions/4113934/how-is-oauth-2-other-from-oauth-1
• http://googlecodesamples.com/oauth_playground/

Мы Варонис.

С 2005 года мы защищаем самые ценные в мире данные от врагов с помощью нашей ведущей на рынке платформы защиты данных.

Роб Соберс

Роб Соберс — инженер-программист, специализирующийся на веб-безопасности, и соавтор книги Learn Ruby the Hard Way.

Продолжайте читать

Что такое OAuth 2.0 и чем он вам полезен?

OAuth 2.0, что означает «Открытая авторизация», — это стандарт, разработанный для предоставления веб-сайту или приложению доступа к ресурсам, размещенным другими веб-приложениями, от имени пользователя. Он заменил OAuth 1.0 в 2012 году и теперь является отраслевым стандартом де-факто для онлайн-авторизации. OAuth 2.0 обеспечивает согласованный доступ и ограничивает действия, которые клиентское приложение может выполнять с ресурсами от имени пользователя, никогда не передавая учетные данные пользователя.

Хотя Интернет является основной платформой для OAuth 2, в спецификации также описывается, как обрабатывать такой делегированный доступ к другим типам клиентов (браузерным приложениям, серверным веб-приложениям, собственным/мобильным приложениям, подключенным устройствам и т. д.). .)

Принципы OAuth3.0

OAuth 2.0 — это протокол авторизации, а НЕ протокол аутентификации. Таким образом, он разработан в первую очередь как средство предоставления доступа к набору ресурсов, например, к удаленным API или данным пользователя.

OAuth 2.0 использует токены доступа. Маркер доступа — это фрагмент данных, который представляет собой авторизацию для доступа к ресурсам от имени конечного пользователя. OAuth 2.0 не определяет конкретный формат токенов доступа. Однако в некоторых случаях часто используется формат JSON Web Token (JWT). Это позволяет эмитентам токенов включать данные в сам токен. Кроме того, по соображениям безопасности токены доступа могут иметь срок действия.

Роли OAuth3.0

Идея ролей является частью основной спецификации структуры авторизации OAuth3.0. Они определяют основные компоненты системы OAuth 2.0 и заключаются в следующем:  

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

• Клиент : Клиент — это система, которой требуется доступ к защищенным ресурсам. Для доступа к ресурсам Клиент должен иметь соответствующий Токен доступа.

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

• Сервер ресурсов : Сервер, который защищает ресурсы пользователя и получает запросы на доступ от Клиента. Он принимает и проверяет токен доступа от клиента и возвращает ему соответствующие ресурсы.

Области действия OAuth 2.0

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

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

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

Как работает OAuth 2.0?

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

При использовании OAuth 2.0 запросы на доступ инициируются Клиентом, например мобильным приложением, веб-сайтом, приложением Smart TV, настольным приложением и т. д. Запрос токена, обмен и ответ следуют следующему общему потоку:

1. Клиент запрашивает авторизацию ( запрос авторизации ) с сервера авторизации, предоставляя идентификатор клиента и секрет для идентификации; он также предоставляет области и URI конечной точки ( URI перенаправления ) для отправки токена доступа или кода авторизации.

2. Сервер авторизации аутентифицирует Клиента и проверяет, разрешены ли запрошенные области.

3. Владелец ресурса взаимодействует с сервером авторизации для предоставления доступа.

4. Сервер авторизации перенаправляет обратно клиенту код авторизации или токен доступа, в зависимости от типа предоставления, как это будет объяснено в следующем разделе. Также может быть возвращен Refresh Token.

5. С помощью маркера доступа клиент запрашивает доступ к ресурсу с сервера ресурсов.

Типы грантов в OAuth 2.0

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

• Код авторизации предоставление : Сервер авторизации возвращает одноразовый код авторизации Клиенту, который затем обменивается на Токен доступа. Это лучший вариант для традиционных веб-приложений, где обмен может безопасно происходить на стороне сервера. Поток кода авторизации может использоваться одностраничными приложениями (SPA) и мобильными/собственными приложениями. Однако здесь секрет клиента не может быть надежно сохранен, поэтому аутентификация при обмене ограничивается использованием идентификатор клиента один. Лучшей альтернативой является код авторизации с грантом PKCE , как показано ниже.

• Неявный Предоставление : Упрощенный поток, при котором токен доступа возвращается непосредственно клиенту. В неявном потоке сервер авторизации может вернуть токен доступа в качестве параметра в URI обратного вызова или в качестве ответа на сообщение формы. Первый вариант теперь устарел из-за потенциальной утечки токена.

• Предоставление кода авторизации с ключом подтверждения для обмена кодами (PKCE) : Этот поток авторизации аналогичен предоставлению кода авторизации , но с дополнительными шагами, которые делают его более безопасным для мобильных/собственных приложений и SPA.

  No related posts.