Выдача новых oauth токенов что это значит

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

Разбираемся, как работает протокол OAuth 2.0 и OpenID Connect. Почему Authorization Code Grand лучший способ получения access token.

• 

Если коротко 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. На анимации ниже, я постарался схематично изобразить, как реализовать этот пример правильно с помощью Oauth2. Стоит учитывать, что у Google есть свой сервер авторизации, который отвечает за авторизацию на любом сервисе Google. Поэтому Gmail только хранит ресурсы, но не отвечает за авторизацию.

Весь смысл в том, что Клиент должен получить каким-то образом от авторизационного сервера 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 .

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

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

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

Resource Owner Password Credential

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

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

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

Authorization Code Grand

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

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

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

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

• response_type — Обозначает тип учетных данных, которые возвращает авторизационный сервер. Для этого способа значение должно быть code .
• redirect_uri — URL-адрес, на который авторизационный сервер будет перенаправлять браузер после авторизации пользователя. Код авторизации будет доступен в параметре code .

В настройках Авторизационного сервера можно настроить url адреса, на которые разрешен редирект.

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

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

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

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

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

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

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.

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

Заключение

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

Источник

Работа с токенами OAuth при проверке подлинности Службы приложений Azure

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

Извлечение токенов в коде приложения

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

Поставщик	Имена заголовков
Azure Active Directory	X-MS-TOKEN-AAD-ID-TOKEN X-MS-TOKEN-AAD-ACCESS-TOKEN X-MS-TOKEN-AAD-EXPIRES-ON X-MS-TOKEN-AAD-REFRESH-TOKEN
Токен Facebook	X-MS-TOKEN-FACEBOOK-ACCESS-TOKEN X-MS-TOKEN-FACEBOOK-EXPIRES-ON
Google	X-MS-TOKEN-GOOGLE-ID-TOKEN X-MS-TOKEN-GOOGLE-ACCESS-TOKEN X-MS-TOKEN-GOOGLE-EXPIRES-ON X-MS-TOKEN-GOOGLE-REFRESH-TOKEN
Twitter	X-MS-TOKEN-TWITTER-ACCESS-TOKEN X-MS-TOKEN-TWITTER-ACCESS-TOKEN-SECRET

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

Отправьте из клиентского кода (например, мобильного приложения или JavaScript в браузере) HTTP-запрос GET для /.auth/me (необходимо включить хранилище токенов). В возвращаемом JSON-файле будут содержаться предоставляемые поставщиком токены.

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

Обновление маркеров проверки подлинности

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

Google. Добавьте параметр строки запроса access_type=offline к вызову API /.auth/login/google . Если используется пакет SDK для мобильных служб, можно добавить параметр к одной из перегрузок LogicAsync (см. в разделе о токенах обновления Google).

Facebook. Не предоставляет токены обновления. Срок действия токенов с долгим временем существования истекает через 60 дней (см. раздел об истечении и продлении срока действия токенов доступа Facebook).

Twitter. Срок действия токенов доступа не истекает (см. раздел о часто задаваемых вопросах о Twitter OAuth).

Microsoft: в https://resources.azure.com выполните следующие действия.

В верхней части страницы выберите Read/Write (Чтение и запись).

В левой части страницы выберите subscriptions > ** resourceGroups > _ _ > providers > Microsoft.Web > sites > _ _ > config > authsettingsV2.

Нажмите кнопку Изменить.

Измените следующее свойство.

Щелкните Put.

Область, которая предоставляет маркер обновления, offline_access. Узнайте, как она используется в учебнике: проверка подлинности и авторизация пользователей в службе приложений Azure. Другие области по умолчанию запрашиваются службой приложений. сведения об этих областях по умолчанию см. в разделе openid connect Подключение scopes.

После настройки поставщика можно найти токен обновления и срок действия для токена доступа в хранилище токенов.

Обновить маркер доступа можно в любой момент, вызвав команду /.auth/refresh на любом языке. В следующем фрагменте кода jQuery используется для обновления токенов доступа из клиента JavaScript.

Если пользователь отменяет разрешения, предоставленные приложению, вызов /.auth/me может завершиться ошибкой 403 Forbidden . Чтобы выполнить диагностику ошибок, проверьте дополнительные сведения в журналах приложений.

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

Сеанс проверки подлинности истекает через 8 часов. По истечении срока действия авторизованного сеанса по умолчанию предоставляется 72-часовой льготный период. В течение этого льготного периода токен сеанса можно обновить с помощью Службы приложений без повторной проверки подлинности пользователя. Если токен сеанса становится недействительным, вы можете просто вызвать /.auth/refresh , и вам не нужно самостоятельно отслеживать истечение срока действия токена. После завершения 72-часового льготного периода пользователь должен выполнить вход в систему, чтобы получить действительный токен сеанса.

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

Чтобы продлить льготный период истечения срока действия по умолчанию, выполните следующую команду в Cloud Shell.

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

Источник