Oauth2 discord что это

Обновлено: 07.07.2024

Для комфортной разработки ботов и специальных приложений уже давно используется прямое взаимодействие с Discord API. В этом случае для создания виртуальных ассистентов вовсе не требуется обладать полным кодом и понимать всю специфику работы приложения. Будет вполне достаточно использовать уже готовые инструменты, значительно упрощающие процесс разработки (как правило, применяются модули Node.js и Python). Также начинающим программистам помогут готовые коды, расположенные на популярных форумах. В общем, предлагаем разобраться с этой темой, остановившись на важных нюансах и особенностях.

Discord API – что это и где найти?

И начнем с того, что Discord API – это программный интерфейс приложения, обращение к которому напрямую значительно упрощает процесс разработки ботов. Как результат – программистам вовсе не нужно обладать полным доступом к исходному коду, а потребуется только использовать уже готовые инструменты. Благодаря этому удастся внедрить авторизацию через Дискорд на сайт, подключить любого помощника к серверу и даже создать приватный канал.

Как подключиться к Discord API при создании бота?

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

Переходим на страницу Дискорд Developers и выполняем авторизацию в своем аккаунте. А после этого заходим во вкладку Bot и нажимаем на кнопку New Application .

Вводим название самого приложения и кликаем Create , дополнительно подтвердив действие.

Как результат – вы успешно подключились к Дискорд API и воспользовались функционалом для разработчиков. Теперь дело за малым – осталось разработать бота и проверить, насколько корректно он работает. Если нужно, то подробные инструкции получится отыскать на YouTube (в основном по английским запросам). Также не забудьте установить само приложение мессенджера, указав в Google «Discordapp API download platform WIN» и посетив официальный сайт.

Как сделать авторизацию через Дискорд?

Периодически на русских и зарубежных форумах, связанных с разработкой, встречается такой вопрос: Discord API authorization frontend – как сделать? Этим интересуются создатели сайтов, которым необходимо сделать авторизацию через популярный мессенджер. На самом деле ничего самим придумывать не придется – достаточно использовать уже готовые инструменты. В это случае – функционал входа OAuth2:

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

Таким образом, мы рассмотрели, для чего нужен Дискорд API и как использовать столь полезную возможность в разработке. Оказалось, что создавать ботов можно и на компьютере с Windows, и с macOS, и даже с Linux. Остались дополнительные вопросы? Будем рады ответить на них в комментариях!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не все клиенты могут гарантировать сохранность 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, и им надо как-то общаться.

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

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

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

Resource Owner Password Credential

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

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

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

Authorization Code Grand

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

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

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

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

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

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

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

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

Implicit Grant

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

Так как 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 и его возможностей. Мы изучим структуру токена и построим его с нуля. Затем рассмотрим наиболее распространенные способы использования.

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

Заключение

На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.

Что такое OAuth 2.0

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

Чем отличаются OpenID и OAuth

Не смотря на то, что объяснений на эту тему уже было много, она по-прежнему вызывает некоторое непонимание.

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

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

получение авторизации
обращение к защищенным ресурсам

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

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

Редирект на страницу авторизации
На странице авторизации у пользователя запрашивается подтверждение выдачи прав
В случае согласия пользователя, браузер редиректится на URL, указанный при открытии страницы авторизации, с добавлением в GET-параметры специального ключа — authorization code
Сервер приложения выполняет POST-запрос с полученным authorization code в качестве параметра. В результате этого запроса возвращается access token

Пример

Редиректим браузер пользователя на страницу авторизации:

Здесь и далее, client_id и client_secret — значения, полученные при регистрации приложения на платформе.

После того, как пользователь выдаст права, происходит редирект на указанный redirect_uri:

Обратите внимание, если вы реализуете логин на сайте с помощью OAuth, то рекомендуется в redirect_uri добавлять уникальный для каждого пользователя идентификатор для предотвращения CSRF-атак (в примере это 123). При получении кода надо проверить, что этот идентификатор не изменился и соответствует текущему пользователю.

Используем полученный code для получения access_token, выполняя запрос с сервера:

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

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

Пример

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

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

Авторизация по логину и паролю

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

Пример

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

Пример

Минусы OAuth 2.0

Во всей этой красоте есть и ложка дегтя, куда без нее?

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

Безопасность OAuth 2.0 во многом основана на SSL. Это сильно упрощает жизнь разработчикам, но требует дополнительных вычислительных ресурсов и администрирования. Это может быть существенным вопросом в высоко нагруженных проектах.

Заключение

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

Социальные сети, потоковая передача контента, воркспейсы – везде мы заходим через учетные записи, которые могут содержать личную информацию. Изолированные приложения становятся взаимосвязанными: Twitter позволяет новостным сайтам твитить напрямую, Discord ищет предполагаемых друзей на Facebook, а Jira создает учетки с помощью профилей Github.

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

Разберем несколько общих терминов. Для упрощения под OAuth будем подразумевать OAuth 2.0.

Владелец ресурса ( Resource Owner ) – объект, предоставляющий доступ к защищенным ресурсам.
Ресурсный сервер ( Resource Server ) – сервер, на котором размещаются защищенные ресурсы и обрабатываются запросы на доступ.
Клиент ( Client ) – приложение, которое хочет получить доступ к ресурсному серверу и выполнять действия от имени владельца ресурса. Конфиденциальным клиентам (серверные приложения) можно доверять надежное хранение токена, необходимого для доступа к ресурсам, а публичным (мобильные и JS-приложения) – нельзя.
Сервер авторизации ( Authorization Server ) – сервер, который знает владельца ресурса и может авторизовать клиента для доступа к ресурсному серверу.

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

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

Рис. 1. Используя OAuth, клиент (Spotify) может получить доступ к ресурсному серверу (Facebook) без учетных данных от имени владельца ресурса (Боба).

При выводе всплывающего окна OAuth работает в фоновом режиме (Рис. 2):

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

Области и токены OAuth

Области и токены OAuth реализуют детализированное управление доступом. Похоже на киносеанс: область – название фильма, который вы имеете право смотреть, токен – билет, что может проверить лишь сотрудник конкретного кинотеатра.

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

Условно можно выделить четыре типа областей:

доступ для чтения;
доступ на запись;
доступ для чтения и записи;
без доступа.

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

Существует еще один тип токенов – обновляемый (refresh tokens), который используется для автоматического получения нового экземпляра, когда старый больше не функционируют ( e xpired). Такие приложения, как Facebook, могут обеспечить ещё б ó льшую степень защиты, периодически проверяя авторизацию с помощью принудительного использования дополнительных refresh -токенов для получения access -токенов . R efresh tokens имеют важную особенность: они могут быть отозваны путем их аннулирования и возврата клиентского доступа к привилегированным ресурсам.

Рис. 3. OAuth поток

Разрешения и потоки OAuth

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

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

перейти на сайт театра;
найти сеанс;
добавить билет в заказ;
оплатить;
получить билет на e-mail.

Разрешения (grants) диктуют клиенту порядок операций по получению access-токена. Этот уникальный порядок называется потоком.

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

Изучим описанные концепции на примере. Teleport – опенсорсный инструмент удаленного доступа, позволяющий юзерам входить в систему через Github single sign-on (SSO) с использованием OAuth. Действующие лица :

Client : Teleport.
Resource Owner : пользователь Teleport.
Authorization Server : сервер авторизации Github ( GAS ).
Resource Server : ресурсный сервер Github ( GRS ).

Рассмотрим поток шаг за шагом.

Шаг 1. Пользователь Teleport получает доступ к приложению Teleport.

Шаг 2. Приложение предлагает пользователю Teleport войти с помощью Github SSO.

Собрав воедино все, получим следующую строку приглашения:

Шаг 4. Как только GAS получит запрос, он проверит client_id в реестре. Зная, что Teleport ожидает код авторизации, GAS отправит пользователя обратно на URL-адрес с переданными параметрами:

Шаг 5. После получения кода Teleport автоматически попросит GAS обменять код на токен с параметрами code , redirect_uri и client_id . Для обмена используется POST- запрос :

Шаг 6. Используя client_secret и code , сервер авторизации может проверить запрос клиента Teleport и выдать токен, в который зашивается область и время жизни:

Шаг 7. Теперь, когда маркер получен, делаем запрос к API от имени пользователя Teleport и получаем желаемое:

Шаг 8. Н аконец, GitHub API пропускает юзера.

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

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

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

Я пытаюсь добавить Discord OAuth в мобильное приложение с помощью PKCE. Я могу успешно пройти аутентификацию с помощью DiscordAPI и получаю code обратно с сервера.

Я попробовал несколько подходов к получению моего токена, но все они провалились.

Я также попытался использовать объект StringContent , например так:

Оба эти результата в Bad Request

Попытка (2) с помощью RestSharp

Дополнительная информация:

Чтобы соответствовать PKCE, мне нужен code_verifier . Вот как я генерирую код. (Обратите внимание, я не пытаюсь использовать это как код авторизации.)

Я передаю результат как code_challenge , получая свой код авторизации.

Вот где я узнал, что PKCE был необходим.

Обновление:

Тем не менее, этот рабочий процесс PKCE недокументирован . Поскольку я потратил 500 баллов, я начисляю баллы тому, кто сможет разрешить рабочий процесс PKCE OAuth.

2 ответа

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

Клиент запрашивает код с сервера раздора
Клиент отправляет этот код на ваш сервер
Ваш сервер передает код на дискорд-сервер со своими секретами
Сервер Discord отвечает обратно на настроенный redirect_uri, чтобы получить токен.

Примечание: есть 2 перенаправления uri, 1, который разрешает код, и другой, который разрешает токен.

Затем Discord ответит вашему redirect_uri коду и состоянию

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

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

Обратите внимание, что при отправке запроса на конечную точку токена вы используете

'Content-Type': 'application / x-www-form-urlencoded'

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

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

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

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

Читайте также: