Client secret что это

OAuth 2

Клиент это приложение которое пытается получить доступ к учетной записи пользователя. Для этого клиенту нужны разрешения от пользователя.

API: Сервер ресурсов

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

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

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

Пользователь, владелец ресурса

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

Создание приложения

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

Redirect URIs

Сервис только перенаправляет пользователей на зарегистрированный URI, чтобы уменьшить риск некоторых атак. Любое HTTP перенаправление должно выполняться через HTTPS. Это защищает токены от перехвата во время процесса авторизации. Нативные приложения могут регистрировать URI перенаправления используя собственную URL схему для приложения, которая может выглядеть так demoapp://redirect .

Client ID, Secret

После регистрации приложения, будут получены идентификатор клиента Client ID (UID) и секрет (secret). Client ID это публичный информация, и используется открыто для формирования URL, или включения в JavaScript-код приложения на странице. Secret должен сохраняться в тайне и не передаваться в публичный доступ. Если приложение не имеет возможности хранить Secret в безопасности, например это SPA-страница, или нативные приложения, то Secret не используется, и в идеале секрет не должен выдаваться для таких приложений.

Авторизация

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

OAuth 2 предоставляет несколько типов разрешений для разных случаев применения

• Authorization Code для приложений выполняемых в браузере, основанных на браузерных технологиях и мобильных приложений
• Password для входа с именем пользователя и паролем ((only for first-party apps)
• Client credentials для приложений без ассоциации с пользователем
• Implicit — ранее этот тип был рекомендован для клиентов без Secret, но был заменен на способ предоставления кода авторизации PKCE.

Web Server Apps

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

Авторизация

https://auth.server/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=user&state=1234x

• response_code=code — указывает, что сервер должен вернуть код авторизации
• client_id — идентификатор приложения, которое мы создали в сервисе
• redirect_uri — URL куда направить пользователя после завершения авторизации
• scope — область доступа
• state — случайная строка

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

https://my.app/callback?code=AUTH_CODE&state=1234x

• code — код авторизации
• state — строка из запроса авторизации

Мы должны проверить state чтобы убедиться что это «наш» запрос, мы его инициировали. Обычно значение state сохраняется в cookie или сессии, и сравнивается после получения ответа. Это создает гарантию, что точку перенаправления нельзя обмануть отправляя произвольными кодами авторизации.

Получение токена доступа

Для получения токена отправляем POST запрос, указывая полученный код авторизации

POST https://auth.server/oauth/token grant_type=authorization_code& code=AUTH_CODE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& client_secret=CLIENT_SECRET 

• grant_type=authorization_code — тип
• code=AUTH_CODE — код, полученный от сервера авторизации
• redirect_uri=REDIRECT_URI — должен соответствовать URI указанному в настройка приложения в сервисе
• client_id=CLIENT_ID — идентификатор приложения в сервисе
• client_secret=CLIENT_SECRET — так как запрос отправляется на стороне сервере, можем включить секрет

Single-Page Apps (SPA)

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

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

Авторизация

Создать случайную строку длиной 43-128 символов, затем сгенерировать url-безопасный base64 SHA256 хеш на основе этой строки. Оригинальная строка будет называться code_verifier , в хеш версия code_challenge

Например, строка, code_verifier

5d2309e5bb73b864f989753887fe52f79ce5270395e25862da6940d5

Hash, SHA256, base64-encoded, code_challenge

MChCW5vD-3h03HMGFZYskOSTir7II_MMTb8a9rJNhnI

Строка входа будет такой

https://auth.server/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=user&state=123x&code_challenge=CODE_CHALLENGE&code_challenge_method=S256

• response_type=code — сервер должен возвратить код авторизации
• client_id — ID приложения
• redirect_uri — адрес перенаправления
• scope — область доступа
• state — случайная строка для проверки запроса
• code_challenge — хеш, основанный на случайной строке, временный секрет
• code_challenge_method — метод хеширования

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

https://my.app/callback?code=AUTH_CODE&state=123x

После проверки идентичности state , можно запросить токен.

Получение токена доступа

Теперь отправляем POST запрос с кодом авторизации, но добавляем в параметры вместо секрета приложения, PKCE секрет, созданный ранее

POST https://auth.server/oauth/token grant_type=authorization_code& code=AUTH_CODE& redirect_uri=REDIRECT_URI& client_id=CLIENT_ID& code_verifier=CODE_VERIFIER

Здесь CODE_VERIFIER — это секрет созданные нами в самом начале. Сервер преобразует CODE_VERIFIER в hash и сравнит с кодом отправленным ранее.

Мобильные приложения

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

Авторизация

Следует направить пользователя либо в нативное приложение сервиса на телефоне, либо на мобильную страницу сервиса. Приложение может регистрировать нестандартную схему например my-app:// , чтобы запускалось нативное приложение.

Например если установлено приложение Facebook, адрес авторизации может быть таким

fbauth2://autorize?response_type=code&client_id=ID&redirect_uri=URI&scope=email&state=123x

Другие типы

Password

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

Для получения токена достаточно отправить простой POST запрос

POST https://aut.server/oauth/token grant_type=password& username=USERNAME& password=PASSWORD& client_id=CLIENT_ID

• grant_type=password — тип
• username=USERNAME — реальное имя пользователя
• password=PASSWORD — реальный пароль пользователя
• client_id=CLIENT_ID — идентификатор приложения в сервисе

Сервер пришлет в ответе токен доступа.

Здесь также Client Secret не включен в запрос, предполагая что основные области использования потока password это мобильные и веб-приложения, где безопасно хранить Secret возможности нет.

Доступ приложений

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

POST https://auth.server/oauth/token grant_type=client_credentials& client_id=CLIENT_ID& client_secret=CLIENT_SECRET

В данном случае подразумевается, что запросы выполняются на стороне сервера.

Запросы

После получения токена можно выполнять запросы к защищенным данным

curl -H 'Authorization: Bearer ' \ https://api.server/api/v1/me

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

Sign up for more like this.

Enter your email

slimrb

Преобразование Slim в Erb. slimrb консольная утилита запускается в командной строке. Использование Slim в качестве основного шаблонизатора очень удобно и продуктивно. Но накладывает ограничения на форматирование. Не всегда удобно, когда в команде работают специалисты разного уровня подготовки. Для сложных и объемных страниц может быть сложным. Slim — супер решение, но

13 июня 2023 г. 1 min read

Nuxt: взгляд в 2023

Результатом многолетней работы стал не только выпуск новой версии Nuxt (3), но новая архитектура, функциональная серверная среда (Nitro) и новая организационная экосистема в Github (UnJs)

25 янв. 2023 г. 1 min read

Получение данных в Nuxt

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

Инструкция с картинками: где взять Clinet ID и Client Secret для Oauth2-авторизации через Google+?

Для Oauth2-авторизации на вашем сайте при помощи зарубежной социальной сети «Google+» вам понадобятся Clinet ID и Client Secret.

Помните! Clinet ID и Client Secret — это секретная информация! Её нельзя публиковать, это запрещено правилами Гугла. Поэтому, кстати, все данные на скриншотах я заменил на фиктивные — не пытайтесь их никуда скопировать, не сработает.

Для начала убедитесь, что у вас есть аккаунт в Гугл. Если у вас уже есть Gmail или аккаунт на Youtube, то, значит, есть и аккаунт в Google, так как он един для всех сервисов этой компании. Если же нет, то вначале зарегистрируйтесь (ссылка «Создать аккаунт»). При регистрации я бы рекомендовал указывать ваши реальные фамилию, имя, отчество, действительный номер телефона и загрузить фотографию. Всё-таки, случись что, если у вас указаны реальные данные, вы сможете, связавшись с администрацией ресурса, подтвердить, что являетесь владельцем аккаунта (по крайней мере, будет больше на то шансов).

Имея аккаунт в Google, вы теперь можете приступить к созданию приложения для Oauth2-авторизации и получению Clinet ID и Client Secret.

1. Сначала зайдите в консоль разработчиков Гугла. Если вы там впервые, вам предложат зарегистрироваться. Следуйте инструкциям. После этого вы попадёте на дэшборд.

2. На дэшборде нажмите на Create Project.

Если вы не в том разделе, то сначала нажмите на Projects

3. Заполните форму. Обратите внимание, что в названии нельзя использовать русские буквы. Я выбрал название «Maslov-5 Development Server». Проекту будет автоматически присвоен id. У гугла они в виде словосочетаний. Например, мне выпало «coral-atom-803». Можете пощёлкать на иконку «Обновить» справа от неё, чтобы подобралось другое. Обязательно отметить галочку, если она у вас есть. Нажмите Create.

4. Теперь слева нажимаем на APIs & Auth, и в нём на Credentials.

5. В нём под разделом OAuth на Create new Cliend ID.

6. В появившемся окошке выбираем Web Application. От нас хотят узнать дополнительные данные. Нажимаем на Configure consent screen.

7. Нас перекидывает на настройки. Нужно указать ваш емейл и имя приложения (как оно будет показываться посетителю, теперь можно и по-русски, я написал «Сервер разработки Маслов-5»). Заполняем и жмём Save.

8. Снова попадаем на окно создания Client ID. На этот раз нам предлагают ввести Authorised javascript origins (обычно это адрес сайта) и Authorised redirect uris для oauth2.
В моём случае это «http://dev5.maslov.co/» и «http://dev5.maslov.co/user/index/sociallogin/provider/g/» соответственно.
Вводим и, наконец, жмём на Create Client ID.

9. Система призадумается на какое-то время, а затем, возможно, снова покажет нам окошко этих же настроек. Позади него уже видны нужные нам данные! Окошко, если оно появилось, можно закрыть кнопкой Cancel.

Вопрос к следующему этой инструкции: на пункте 9 появилось ли окошко? У меня первый раз появилось, а когда регал второй сайт— нет.

10. А вот за этим-то мы и пришли! Я не имею права публиковать свои Clinet ID и Client Secret, поэтому на скриншоте я их скрыл.

Готово! Теперь у вас есть Clinet ID и Client Secret, используйте их по назначению!

You can leave a comment with «Facebook»:

Client secret

При регистрации Приложения Партнера клиентский менеджер передает значения Client ID и Client Secret, присвоенные приложению.

Партнеру в обязательном порядке требуется сменить полученный Client Secret. Существуют следующие способы смены Client Secret:

• Через Личный кабинет SberBusinessAPI
• С использованием ресурса /v1/change-client-secret

Срок действия Client Secret составляет 40 дней.

Client Secret должен своевременно обновляться, в противном случае доступ к ресурсам СберБизнес ID, SberBusinessAPI и /v1/change-client-secret будет заблокирован.
В случае блокировки Client Secret Приложения Партнера можно разблокировать через отделение банка, менеджера или Личный кабинет SberBusinessAPI.

Ресурс /v1/change-client-secret 

Хост для вызова ресурса /v1/change-client-secret см. в разделе Область сведений и атрибуты.

Для смены Client Secret необходимо отправить POST-запрос /v1/change-client-secret.

Модель запроса 

Наименование	Описание
access_token	String

Пример запроса 

POST /ic/sso/api/v1/change-client-secret Host: edupirfintech.sberbank.ru:9443 access_token=c68c8524-7546-4ab2-92cb-8822d82110a4-1 &client_id=03e0be32-e72e-47ec-b740-a00b333a8ac4-1 &client_secret=740464ba79c248d9be6c525a09471cca &new_client_secret=da658d9360604e41a5bac9611d0f1620 

Необязательный параметр client_id позволяет изменять Client Secret любых Приложений зарегистрированных на одного Партнера.

Например:

У Партнера ООО «Ромашка» зарегистрировано два приложения с:

• client_id = 10010 , client-secret = XXXXXXX
• client_id = 20020 , client-secret = PPPPPPP

Пользователь ООО «Ромашка» авторизуется в приложении с client_id = 10010 и получает Access Token = c68c8524-7546-4ab2-92cb-8822d82110a4-1

Приложение Партнера вызывает ресурс /v1/change-client-secret, где указывает:

• access_token = c68c8524-7546-4ab2-92cb-8822d82110a4-1
• client_id = 20020
• client_secret = PPPPPPP
• new_client_secret = NNNNNN

В этом случае Client Secret будет изменен для client_id = 20020

Если Приложение Партнера вызывает ресурс /v1/change-client-secret, где указывает:

• access_token = c68c8524-7546-4ab2-92cb-8822d82110a4-1
• client_secret = XXXXXXX
• new_client_secret = NNNNNN

То в этом случае Client Secret будет изменен для client_id = 10010 , т.к. параметр client_id не указан, а Access Token выдан для приложения с client_id = 10010

Модель ответа 

Наименование	Описание
clientSecretExpiration	Number Срок действия нового Client Secret (в днях)

Пример ответа 

  "clientSecretExpiration":40 > 

OAuth 2.0 — основы понятным языком

Рассмотрим типичную ситуацию. Вы нашли в интернете интересный ресурс (пусть это будет к примеру портал онлайн-курсов coursera.org), но чтобы им полноценно воспользоваться, нужно создать личный аккаунт и войти в него. Вас не особо радует необходимость «стопятьсот» раз проходить нудную процедуру регистрации: придумывать логин и пароль, вводить личные данные, потом как-то это все запоминать.

Високорівневий курс від laba: Фінансовий аналіз.
Оцінюйте фінансову стабільність та перспективи.

Тем не менее, скрепя сердце, вы нажимаете «Войти» и в открывшейся форме обнаруживаете вдруг решение в виде кнопок входа через аккаунты социальной сети. Выбираете любимую соцсеть, например Facebook. Кликаете, после чего вас перебрасывает на форму авторизации. Там вы указываете свои логин и пароль в Facebook. Далее вам предложат разрешить доступ приложению ресурса к вашему аккаунту. Подтверждаете. И все — вы каким-то магическим образом вошли на ресурс, используя регистрационные данные от Facebook. Никаких новых паролей, имен пользователя, заполнения прочих полей не потребовалось.

Для реализации подобных сценариев (а также множества аналогичных) и предназначен стандарт OAuth 2.0.

Что такое OAuth 2.0?

OAuth 2.0 (RFC 6749) является открытым фреймворком авторизации, позволяющим получить сторонним приложениям ограниченный доступ к ресурсам HTTP-сервиса.

Ефективний курс від robotdreams: Software Architect.
Від ідеї до коду.

История создания

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

В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В ее работе приняли участие сотрудники компаний Google и AOL. Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. 15 апреля 2009 года Twitter предложил пользователям решение, позволяющее делегировать сторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Twitter» и основано на OAuth.

В апреле 2010 года был выпущен информационный документ RFC 5849, посвященный стандарту OAuth. В 2010 году началась работа над новой версией протокола OAuth 2.0. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, а использование носителя токена регламентировано в RFC 6750. Вторая версия была несовместима с первой.

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

В результате в новый протокол было внесено несколько важных изменений:

• Упрощенная подпись. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
• Короткоживущие токены с долговременной авторизацией. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
• Разделение ролей. За авторизацию и за предоставление доступа к API могут отвечать разные серверы.

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

Програмний курс від robotdreams: С++ для GameDev.
Розробка ігор на високому рівні.

Отличие от OpenID

Часто можно услышать такой вопрос. А зачем нужен OAuth, если существует OpenID? Хотя OAuth и OpenID имеют много общего, между ними есть принципиальная разница:

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

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

Стандарт OAuth 2.0 определяет следующие четыре роли :

1. владелец ресурса — сущность, обладающая правом на выдачу доступа к защищенным ресурсам. В случае если владелец является человеком, его называют конечным пользователем;
2. сервер ресурсов — сервер, содержащий защищаемые ресурсы и обладающий возможностью получения и формирования ответа на запросы к защищаемым ресурсам посредством использования маркера доступа;
3. клиент — приложение, осуществляющее доступ к защищенным ресурсам от имени владельца. Термин «клиент» явно не определяет какое-либо конкретное исполнение (будь то сервер, персональный компьютер или мобильное приложение);
4. сервер авторизации — сервер, осуществляющий выпуск маркеров доступа для клиентских приложений после успешной аутентификации и авторизации владельца ресурсов.

Общая схема взаимодействия выглядит следующим образом:

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

Інтенсивний курс від laba: Product management.
Від ідеї до успішного продукту.

Таким образом имеется:

• Конечный пользователь (вы).
• Клиент (приложение сайта на котором мы хотим авторизоваться coursera.org).
• Сервер авторизации (приложение социальной сети Facebook, аккаунт, которой мы хотим использовать). В данном случае он же будет являться и сервером ресурсов, но вообще это могут быть разные приложения.

1. Клиент запрашивает у конечного пользователя прохождение авторизации на сервере авторизации (в приведенном примере, это когда пользователя перенаправляют на страницу логина Facebook, затем запрашивают разрешение на доступ из приложения клиента).
2. После того как конечный пользователь авторизовался, клиент получает грант авторизации. (Фактически грант авторизации клиенту выдает сервер авторизации, после того как конечный пользователь авторизовался и подтвердил выдачу запрашиваемых клиентом прав.)
3. Клиент запрашивает у сервера токен доступа. При этом клиент предоставляет некоторые идентификационные данные о себе и грант авторизации от пользователя. Токен доступа представляет собой альтернативу логину и паролю, имеет ограниченное время действия и связан с определенными ограничениями прав. Отметим, что клиент должен быть предварительно зарегистрирован на сервере авторизации, чтобы можно было его идентифицировать.
4. Если подлинность клиента подтверждена и разрешение на авторизацию действительно, сервер авторизации создает токен доступа для клиента и передает его. Авторизация завершена.
5. Клиент использует токен доступа для аутентификации на сервере авторизации.
6. Клиент получает доступ к необходимым ресурсам (читает данные аккаунта пользователя Facebook и создает на ее основе свою учетную запись).

Итак, чтобы запросить токен доступа, клиент получает авторизацию от владельца ресурса. Разрешение выражается в виде гранта авторизации ( authorization grant ), который клиент использует для запроса токена доступа ( access token ). OAuth определяет четыре типа предоставления:

1. код авторизации ( authorization code ),
2. неявный ( implicit ),
3. учетные данные владельца ресурса,
4. учетные данные клиента.

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

Код авторизации (авторизация для приложений, имеющих серверную часть)

Код авторизации (авторизация для приложений, имеющих серверную часть).

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

Пример

Примеры приводятся для API Mail.Ru. Перенаправляем браузер пользователя на страницу авторизации:

> GET /oauth/authorize?response_type=code&client_id=464119& redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1.1 > Host: connect.mail.ru

client_id и client_secret — значения, полученные при регистрации приложения на платформе. После того, как пользователь выдаст права, происходит перенаправление на указанный redirect_uri :

Используем полученный code (код авторизации) для получения токена доступа, выполняя запрос с сервера:

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_code&client_id=464119&client_secret=deadbeef&code=DoRieb0y& redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 < HTTP/1.1 200 OK < Content-Type: application/json

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

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

> GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo& sig=. HTTP/1.1 > Host: appsmail.ru

Неявный (Авторизация полностью клиентских приложений)

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

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

Пример

Открываем браузер со страницей авторизации:

> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Host: connect.mail.ru

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

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

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

Авторизация по логину и паролю представляет простой POST -запрос, в результате которого возвращается токен доступа. Данная схема вставлена в стандарт для общности и рекомендуется к применению тогда, когда другие варианты авторизации не доступны.

Пример

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&[email protected]& password=qwerty < HTTP/1.1 200 OK < Content-Type: application/json

Учетные данные клиента

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

Восстановление предыдущей авторизации

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

Пример

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8 < HTTP/1.1 200 OK < Content-Type: application/json

Зачем нужен Authorization Code

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

Дело в том, что это безопаснее. Канал между приложениями (клиентом и сервером ресурсов) безопасный ( back сhannel ). А канал запросов, проходящих через браузер ( front channel ), — нет. Код авторизации проходит через браузер: он возвращается в url при перенаправлении обратно на клиент. Для обращения к ресурсам прошедший через браузер код авторизации не очень подходит. Его относительно легко может перехватить злоумышленник. Поэтому он заменяется на токен доступа, пересылаемый через безопасный канал ( back сhannel ). Кроме того, без секрета клиента ( client-secret , который также передается по back сhannel ) токен доступа не получить, что обеспечивает дополнительную безопасность.

Зачем нужен refresh токен?

Допустим, кто-то завладел вашим токеном доступа и получил доступ к защищенным данным. Именно поэтому у токенов есть срок годности. У токена доступа он обычно небольшой — от нескольких секунд до нескольких дней, у токена обновления — много больше. Так вот: доступ к данным у злоумышленника будет до тех пор, пока токен доступа не «протухнет», то есть недолго.

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

Преимущества и недостатки OAuth 2.0

Из плюсов протокола OAuth 2.0 можно выделить следующее:

• Обращение к ресурсам происходит по HTTP/HTTPS с указанием токена в заголовках. Это позволяет использовать OAuth практически в любых решения: мобильных и десктоп-приложениях, сайтах и даже в плагинах для браузеров.
• Возможность авторизации пользователя.
• Популярность — большинство компаний используют его в своих API.
• Простота реализации и большое количество литературы.
• Наличие готовых решений, которые можно изменять под свои нужды.

Из минусов:

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

Итоги

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

В целом, OAuth 2.0 исправляет недостатки OAuth 1.0, но имеет ряд своих недостатков. На данный момент он все еще находится в развитии. Следующая ожидаемая версия стандарта — OAuth 2.1.

Закрепить озвученный материал можно в этом тематическом видео: