Где посмотреть токен ключ авторизации

Как получить токен пользователя для ВКонтакте?

Пытаюсь получить токен. Читал документацию, ничего не понял. Что делать ?

Илья

Токены — это ключи доступа к API. Они используются для авторизации при запросах к API.

Токены позволяют ограничивать доступ к данным пользователя с помощью параметра scope . Он определяет рамки видимости для вашего приложения. Токен с scope=friends даёт доступ к друзьям и ни к чему больше. Таким образом, токен становится менее опасным, чем логин и пароль.

Как получить

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

1. Создайте Standalone приложение.

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

2. Достаньте его client_id

Снова перейдите на страницу с вашими приложениями. Нажмите на кнопку «Редактировать» рядом с нужным приложением. В адресной строке появится его id . Из этой ссылки: https://vk.com/editapp?id=678295892 видно, что client_id=678295892 .

3. Соберите ссылку для получения ключа

Пример ссылки из документации Implicit Flow:

https://oauth.vk.com/authorize?client_id=1&display=page&scope=friends&response_type=token&v=5.92&state=123456

• redirect_uri указывать не надо т.к. сайт вам не нужен, приложение же клиентское.
• response_type и display оставьте такими, как в примере.
• client_id вы получили на втором шаге.
• v возьмите со страницы с версиями API. Выберите самую свежую.

scope выбирайте в зависимости от методов, которые хотите использовать. Например, для доступа к методу wall.post в документации ясно сказано: «требуются права доступа: wall«.

Параметр scope указывайте через запятую, вот так: scope=photos,groups .

4. Перейдите по собранной ссылке

Вы получите access_token — строку наподобие 533bacf01e1165b57531ad114461ae8736d6506a3 . Она появится в адресной строке, подписанная как access_token . Если в адресной строке появился code= вместо access_token= , проверьте правильность параметра response_type .

Что читать

• Статья от Mail.ru OAuth 2.0 простым и понятным языком
• Статья от Digital Ocean Введение в OAuth 2
• Implicit Flow ВКонтакте

Попробуйте бесплатные уроки по Python

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

Переходите на страницу учебных модулей «Девмана» и выбирайте тему.

Авторизация

Для работы с API продуктов Selectel используются токены Keystone и токены Selectel (ключи API). Используемый токен зависит от продукта.

Если вы используете Windows, в запросах замените одинарные кавычки ( ’’ ) на двойные ( «» ).

Токен Keystone

Токен Keystone можно выписать только сервисному пользователю.

Токен Keystone дает доступ к управлению большинством продуктов Selectel и объектами OpenStack API наравне с логином и паролем в панели управления my.selectel.ru.

Токен Keystone позволяет управлять:

• балансом и потреблением;
• пользователями (IAM);
• выделенными серверами;
• объектами OpenStack API (облачными серверами, сетевыми дисками и другими), подробнее в документации OpenStack;
• облачной платформой (облачными базами данных, Managed Kubernetes, Container Registry, облачными функциями, менеджером секретов);
• объектным хранилищем (Swift API и Selectel Storage API);
• CDN;
• DNS-хостингом.

Выписать токен можно:

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

Токен передается в заголовке X-Auth-Token в каждом запросе. Время жизни токена — 24 часа.

Получить токен Keystone

Адрес (URL): cloud.api.selcloud.ru

Токен для аккаунта

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

• Администратор аккаунта;
• Администратор биллинга;
• Администратор пользователей;
• Наблюдатель аккаунта.

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

curl -i -X POST \ -H 'Content-Type: application/json' \ -d '","domain":">,"password":"">>>,"scope":<"domain":">>>>' \ https://cloud.api.selcloud.ru/identity/v3/auth/tokens 

• — имя сервисного пользователя. Посмотреть имя можно в панели управления: в правом верхнем углу откройте меню → Профиль и настройки → раздел Управление пользователями → вкладка Сервисные пользователи (раздел доступен только Владельцу аккаунта и Администратору пользователей);
• — номер аккаунта в панели управления;
• — пароль сервисного пользователя, можно посмотреть при создании пользователя или изменить на новый.

При успешной авторизации сервис авторизации вернет ответ с кодом 201 Created в формате:

HTTP/2 201 X-Subject-Token: token 

Токен для проекта

Выписывать токены для проекта можно сервисным пользователям с ролями:

• Администратор аккаунта;
• Администратор биллинга;
• Администратор пользователей;
• Наблюдатель аккаунта;
• Администратор проекта;
• Наблюдатель проекта.

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

curl -i -X POST \ -H 'Content-Type: application/json' \ -d '","domain":">,"password":"">>>,"scope":","domain":">>>>>' \ https://cloud.api.selcloud.ru/identity/v3/auth/tokens 

• — имя сервисного пользователя. Посмотреть имя можно в панели управления: в правом верхнем углу откройте меню → Профиль и настройки → раздел Управление пользователями → вкладка Сервисные пользователи (раздел доступен только Владельцу аккаунта и Администратору пользователей);
• — номер аккаунта в панели управления;
• — пароль сервисного пользователя, можно посмотреть при создании пользователя или изменить на новый;
• — имя проекта.

При успешной авторизации сервиса авторизации вернет ответ с кодом 201 Created в формате:

HTTP/2 201 X-Subject-Token: token 

Токен Selectel (ключ API)

Токен Selectel (ключ API) можно выписать только пользователю панели управления.

Токен Selectel дает полный доступ к управлению всеми продуктами Selectel, кроме объектов OpenStack API, наравне с логином и паролем в панели управления my.selectel.ru.

Для продуктов, которые не поддерживают токен Keystone, токен Selectel является единственным:

Токен Selectel передается в запросе в заголовке X-Token . Время жизни токена не ограничено.

Получить токен Selectel

1. В панели управления в правом верхнем углу откройте меню и выберите Профиль и настройки.
2. Перейдите в раздел Ключи API.
3. Нажмите Новый ключ.
4. Введите название ключа и нажмите Создать ключ.

Токен авторизации на примере JSON WEB Token

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

Введение

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

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

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

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

Еще одно небольшое введение

Прежде чем начать говорить о самом токене авторизации следует упомянуть для каких целей вообще его решили использовать. Поскольку мы знаем, что почти весь интернет так или иначе построен на протоколе HTTP(или его старшем брате HTTPS) и что он не отслеживает состояние, то есть при каждом запросе HTTP ничего не знает, что происходило до этого, он лишь передает запросы, то возникает следующая проблема: если аутентификация нашего пользователя происходит с помощью логина и пароля, то при любом следующем запросе наше приложение не будет знать все тот же ли этот человек, и поэтому придётся каждый раз заново логиниться. Решением данной проблемы является как раз наш токен, а конкретно его самая популярная реализация — JSON Web Tokens (JWT). Также помимо решения вопросов с аутентификацией токен решает и другую не менее важную проблему авторизации (разграничение разрешенных данному пользователю действий), о том каким образом мы узнаем ниже, когда начнем разбирать структуру токена.

Формальное определение

Приступим наконец к работе самого токена. Как я сказал ранее в качестве токенов наиболее часто рассматривают JSON Web Tokens (JWT) и хотя реализации бывают разные, но токены JWT превратились в некий стандарт, именно поэтому будем рассматривать именно на его примере.

JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON.

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

Принцип работы

Рассмотрим принцип работы клиент серверных приложений, работающих с помощью JWT. Первым делом пользователь проходит аутентификацию, конечно же если не делал этого ранее и в этом есть необходимость, а именно, например, вводит свой логин и пароль. Далее приложение выдаст ему 2 токена: access token и refresh token (для чего нужен второй мы обсудим ниже, сейчас речь идет именно об access token). Пользователь тем или иным способом сохраняет его себе, например, в локальном хранилище или в хранилище сессий. Затем, когда пользователь делает запрос к API приложения он добавляет полученный ранее access token. И наконец наше приложение, получив данный запрос с токеном, проверяет что данный токен действительный (об этой проверке, опять же, ниже), вычитывает полезные данные, которые помогут идентифицировать пользователя и проверить, что он имеет право на запрашиваемые ресурсы. Таким нехитрым образом происходит основная логика работы с JSON Web Tokens.

Структура токена

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

1. Заголовок (header)
2. Полезные данные (playload)
3. Подпись (signature)

Рассмотрим каждую часть по подробнее.

Заголовок

Это первая часть токена. Она служит прежде всего для хранения информации о токене, которая должна рассказать о том, как нам прочитать дальнейшие данные, передаваемые JWT. Заголовок представлен в виде JSON объекта, закодированного в Base64-URL Например:

Если раскодировать данную строку получим:

Заголовок содержит два главных поля: alg и typ. Поле typ служит для информации о типе токена, но как я уже упоминал ранее, что JWT превратился в некий стандарт, то это поле перестало нести особый смысл и служит скорее для целей будущего, если вдруг появится улучшенная версия алгоритма JWT(2.0), которая заменит JWT. Поле alg задает алгоритм шифрования. Обязательный для поддержки всеми реализациями является алгоритм HMAC с использованием SHA-256, или же, как он обозначен в заголовке, HS256. Для работы с этим алгоритмом нужен один секретный ключ, конкретный механизм работы рассмотрим ниже. Для справки можно также отметить, что существует и асимметричный алгоритм, который можно использовать в JWT, например, RS256. Для работы с ним требуется два ключа — открытый и закрытый. Но в данной статье рассмотрим работу с одним закрытым ключом.

Полезные данные

Перейдем наконец к полезным данным. Опять же — это JSON объект, который для удобства и безопасности передачи представляется строкой, закодированной в base64. Наглядный пример полезных данных (playload) токена может быть представлен следующей строкой:

Что в JSON формате представляет собой:

Именно здесь хранится вся полезная информация. Для данной части нет обязательных полей, из наиболее часто встречаемых можно отметить следующие:

iss — используется для указания приложения, из которого отправляется токен.

user_id — для идентификации пользователя в нашем приложении, кому принадлежит токен.

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

Подпись

На данный момент мы поняли, что пока токен никак не защищен и не зашифрован, и любой может изменить его и тем самым нарушается вообще весь смысл аутентификации. Эту проблему призвана решить последняя часть токена — а именно сигнатура (подпись). Происходит следующее: наше приложение при прохождении пользователем процедуры подтверждения, что он тот за кого себя выдает, генерирует этот самый токен, определяет поля, которые нужны, записывает туда данные, которые характеризуют данного пользователя, а дальше с помощью заранее выбранного алгоритма (который отмечается в заголовке в поле alg токена), например HMAC-SHA256, и с помощью своего приватного ключа (или некой секретной фразы, которая находится только на серверах приложения) все данные токена подписываются. И затем сформированная подпись добавляется, также в формате base64, в конец токена. Таким образом наш итоговый токен представляет собой закодированную и подписанную строку. И далее при каждом новом запросе к API нашего приложения, сервер с помощью своего секретного ключа сможет проверить эту подпись и тем самым убедиться, что токен не был изменен. Эта проверка представляет собой похожую на подпись операцию, а именно, получив токен при новом запросе, он вынимает заголовок и полезные данные, затем подписывает их своим секретным ключом, и затем идет просто сравнение двух получившихся строк. Таким нехитрым способом, если не скомпроментировать секретный ключ, мы всегда можем знать, что перед нами все еще наш %user_name% с четко отведенными ему правами.

Время жизни токена и Refresh Token

Теперь плавно перейдем к следующему вопросу — времени жизни токена, и сопутствующей этой теме refresh token. Мы помним, что одно из важнейших свойств токена — это время его жизни. И оно совсем недолговечное, а именно 10-30 минут. Может возникнуть вопрос: а зачем такое короткое время жизни, ведь тогда придется каждый раз заново создавать новый токен, а это лишняя нагрузка на приложения. А ответ достаточно очевидный, который включает в себя и одновременно ответ на вопрос: а что делать если токен был перехвачен. Действительно, если токен был перехвачен, то это большая беда, так как злоумышленник получает доступ к приложению от имени нашего %user_name%, но так как access token является короткоживущим, то это происходит лишь на недолгий период. А дальше этот токен уже является не валидным. И именно чтобы обновить и получить новый access token нужен refresh token. Как мы знаем (или если забыли можем снова прочитать в начале) пользователь после процесса аутентификацию получает оба этих токена. И теперь по истечении времени жизни access token мы отсылаем в приложение refresh token и в ответ получаем снова два новых токена, опять же один многоразовый, но ограниченный по времени — токен доступа, а второй одноразовый, но долгоживущий — токен обновления. Время жизни refresh token вполне может измеряться месяцами, что достаточно для активного пользователя, но в случае если и этот токен окажется не валидным, то пользователю следует заново пройти идентификацию и аутентификацию, и он снова получит два токена. И весь механизм работы повторится.

Заключение

В данной статье я постарался подробно рассмотреть работу клиент-серверных приложений с токеном доступа, а конкретно на примере JSON Web Token (JWT). Еще раз хочется отметить с какой сравнительной легкостью, но в тоже время хорошей надежностью, токен позволяет решать проблемы аутентификации и авторизации, что и сделало его таким популярным. Спасибо за уделенное время.

Полезные ссылки

1. 5 Easy Steps to Understanding JSON Web Tokens (JWT)
2. JWT — как безопасный способ аутентификации и передачи данных
3. Securing React Redux Apps With JWT Tokens
4. Зачем нужен Refresh Token, если есть Access Token?

Обмен с ЕИС в БП 3.0 КОРП

ЕИС – это Единая информационная система в сфере госзакупок. Обмен через систему ЕИС из 1С Бухгалтерия предприятия 3.0 реализован только в версии КОРП с релиза 3.0.105.31. Организации, которые занимаются поставками по госконтрактам, могут готовить данные для электронного актирования поставки. Электронное актирование – это процесс электронной приемки товаров, работ и услуг, ри которой осуществляется обмен документами в электронном виде между заказчиком и исполнителем госконтракта.

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

Обмен электронными документами будет происходить из рабочего места Текущие дела ЭДО. При этом подключать сервис 1С-ЭДО необязательно.

Для настройки в БП КОРП включите этот функционал в разделе Администрирование – Обмен электронными документами – Обмен с Единой информационной системой в сфере закупок установить галку использования. После этого перейдите по гиперссылке Настройки подключения к личному кабинету ЕИС.

Также проверьте наличие галки в Администрировании – Обмен электронными документами – Сервисы ЭДО, чтобы вы имели возможность зайти в Текущие дела ЭДО

Кнопка Создать. Выберите организацию и выполните все шаги по настройке.

Для заполнения 3 пункта настройки вы можете взять данные из личного кабинета ЕИС в разделе Администрирование – Профиль пользователя:

для заполнения Номер реестровой записи в ЕРУЗ

для заполнения Токен-ключ авторизации

Имеется ограничение – подписывать электронные документы можно только в личном кабинете ЕИС.

Для отправки документа в систему ЕИС не обязательно иметь подключенный сервис ЭДО и настраивать обмен с контрагентом, достаточно настроить интеграцию и нажать в документе кнопку ЭДО – Отправить электронный документ

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

Состояние ЭДО может быть в статусе Закрыт с ошибкой передачи. Это значит, что документ не был принят в личном кабинете ЕИС. В содержании этого электронного документа в 1С можно просмотреть извещение об ошибке и узнать ее причину.

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

Из личного кабинета ЕИС документы в 1С поступают в Текущие дела ЭДО (раздел Покупки/Продажи) в папку Входящие. В колонке Отражение в учете перейдите по ссылке и заполните данные госконтракта.

В шапке укажите Договор контрагента, таким образом вы свяжете госконтракт с договором с покупателем. А в табличной части во вкладке Объекты закупок проверьте, чтобы была указана номенклатура из базы. Если один и тот же товар соответствует разным объектам закупки, то используйте разные элементы справочника Номенклатура.