Как получить access_token вконтакте

Беспарольная аутентификация

Первой реакцией на термин «беспарольная аутентификация» может быть «Как аутентифицировать кого-то без пароля? Разве такое возможно?»

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

Беспарольная аутентификация — это способ конфигурирования процедуры входа и аутентификации пользователей без ввода паролей. Идея такая:

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

Есть похожий метод, при котором вместо одноразовой ссылки по SMS отправляется код или одноразовый пароль. Но тогда придётся объединить ваше приложение с SMS-сервисом вроде twilio (и сервис не бесплатен). Код или одноразовый пароль тоже можно отправлять по почте.

И ещё один, менее (пока) популярный (и доступный только на устройствах Apple) метод беспарольной аутентификации: использовать Touch ID для аутентификации по отпечаткам пальцев. Подробнее о технологии.

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

Medium предоставляет доступ к своему сайту только по почте. Я недавно обнаружил, что Auth0, или Facebook AccountKit, — это отличный вариант для реализации беспарольной системы для вашего приложения.

Что может пойти не так?

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

В чём преимущества?

Как часто вы пользуетесь ссылкой «забыли пароль» для сброса чёртового пароля, который так и не смогли вспомнить после нескольких неудачных попыток входа на сайт / в приложение? Все мы бываем в такой ситуации. Все пароли не упомнишь, особенно если вы заботитесь о безопасности и для каждого сайта делаете отдельный пароль (соблюдая все эти «должен состоять не менее чем из восьми символов, содержать хотя бы одну цифру, строчную букву и специальный символ»). От всего этого вас избавит беспарольная аутентификация. Знаю, вы думаете сейчас: «Я использую менеджер паролей, идиот». Уважаю. Но не забывайте, что подавляющее большинство пользователей не такие техногики, как вы. Это нужно учитывать.

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

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

Сегодня беспарольная аутентификация быстро набирает популярность.

Зачем все это ? JWT vs Cookie sessions

Зачем этот весь геморой ? Почему не юзать старые добрые cookie sessions ? Чем не угодили куки ?

• Нативыным приложениям для сматфонов удобнее работать с токенами. Да есть хаки для работы с куки, но это не нативная поддержка
• Куки в микросерисной архитектуре использовать не вариант. Напомню зачастую микросервисы раскиданы на разных доменах, а куки не поддерживают кросc-доменные запросы
• В микросерисной архитектуре JWT позволяет каждому сервису независимо от сервера авторизации верифицировать токен (через публичный ключ)
• При использовании cookie sessions программист зачастую надеется на то, что предоставил фреймворк и оставляет как есть
• При использовании jwt мы видим проблему с безопасностью и стараемся предусмотреть механизмы контроля в случае каржи авторизационных данных. При использовании cookie сессий программист зачастую даже не задумывается что сессия может быть скомпрометирована
• На каждом запросе использование JWT избавляет бекенд от одного запроса в БД(или кеш) за данными пользователя(, , etc.)

✅ Получение токена через официальное приложение VK.

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

Метод будет рассматривать на примере ВКонтакте для Android. ID такой: 2890984. Именно эту комбинацию надо подставить в ссылку.

Получится следующее:

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

 Права доступа:

В примерах, которые описаны выше, параметр scope содержит многие названия разделов социальной сети ВКонтакте: audio, photos, notify, friends. Это те разделы, которые будут открыты для приложения. Аccess_token может быть использован по-разному. ID, который вы используете, принадлежит доверенному приложению. Именно поэтому вы можете создать access_token, у которого есть все права доступа. Он становится универсальным, так что может быть использован везде.

 access_token:

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

Уже после этого в вашей адресной строке появится необходимый ключ. Он копируется вручную: после access_token= и перед &expires_in.

Ну и закончить стоит несколькими советами:

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

Как делать запросы к API

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

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

Запрос к методам API состоит из шаблона:
где {METHODNAME} — имя метода{PARAMETERS} — параметры, индивидуальные, в зависимости от метода{ACCESS_TOKEN} — ранее сохранённый токен{V} — версия API (на момент написания статья = 5.78)

Зная всё это, сделаем первый запрос, на получение всех личных записей со стены. За стену отвечает сущность wall, а метод его get, который возвращает список всех записей со стены пользователя.
И, в итоге, имя метода будет сформировано в виде —

Так, первая часть URL-адреса уже сформирована:

Теперь нужно определиться с передаваемыми параметрами (PARAMS). Все доступные, обязательные параметры с описанием можно посмотреть на странице метода.
Я буду передавать который соответствует id моего пользователя.

И, можно было бы просто дописать в виде строки к существующему URL-адресу: …?owner_id=120159853

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

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

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

Осталось последний шаг — выполнение http-запроса. И, принимая тот факт, что данные возвращаются в виде JSON, то, результат, нужно дополнительно обернуть в функцию , которая приведёт JSON к обычному PHP-массиву. Вот так просто декодировать JSON.

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

И, исходя из ответа выше, для получения записей выполним:

A step-by-step tutorial on how to get Facebook Access Token

Facebook access token is an opaque string which is used to identify the user, application, or page and can be applied by the application to make graph API calls. Getting token for Facebook page is absolutely free. All you need to do here is open Graph API Explorer and follow these easy steps:

1. Go to Facebook Developer account: .
2. Press Add New App>
3. Press Create App ID and enter the capture into the capture field.
4. Go to and replace Graph API Expolrer with the app you’ve created.
5. Press Get Token and select Get User Access Token.
6. Check the required options on the popup window and choose the permissions needed for your app.
7. Press Get Access Token.
8. Confirm all the requests.
9. Click Info icon next to the token.
10. Press Open in Access Token Tool.
11. Press Extend Access Token.

Now you have read the whole article and if you still have questions, check our FAQ. You may find the answers there.

Структура JWT

JWT состоит из трех частей: заголовок , полезные данные и подпись . Давайте пройдемся по каждой из них.

Шаг 1. Создаем HEADER

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

Поле не говорит нам ничего нового, только то, что это JSON Web Token. Интереснее здесь будет поле , которое определяет алгоритм хеширования. Он будет использоваться при создании подписи. — не что иное, как , для его вычисления нужен лишь один секретный ключ (более подробно об этом в шаге 3). Еще может использоваться другой алгоритм — в отличие от предыдущего, он является ассиметричным и создает два ключа: публичный и приватный. С помощью приватного ключа создается подпись, а с помощью публичного только лишь проверяется подлинность подписи, поэтому нам не нужно беспокоиться о его безопасности.

Шаг 2. Создаем PAYLOAD

Payload — это полезные данные, которые хранятся внутри JWT. Эти данные также называют JWT-claims (заявки). В примере, который рассматриваем мы, сервер аутентификации создает JWT с информацией об id пользователя — userId.

Мы положили только одну заявку (claim) в payload. Вы можете положить столько заявок, сколько захотите. Существует список стандартных заявок для JWT payload — вот некоторые из них:

• iss (issuer) — определяет приложение, из которого отправляется токен.
• sub (subject) — определяет тему токена.
• exp (expiration time) — время жизни токена.

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

Шаг 3. Создаем SIGNATURE

Подпись вычисляется с использование следующего псевдо-кода:

Алгоритм base64url кодирует хедер и payload, созданные на 1 и 2 шаге. Алгоритм соединяет закодированные строки через точку. Затем полученная строка хешируется алгоритмом, заданным в хедере на основе нашего секретного ключа.

Шаг 4. Теперь объединим все три JWT компонента вместе

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

Вы можете попробовать создать свой собственный JWT на сайте jwt.io.
Вернемся к нашему примеру. Теперь сервер аутентификации может слать пользователю JWT.

Как JWT защищает наши данные?

Очень важно понимать, что использование JWT НЕ скрывает и не маскирует данные автоматически. Причина, почему JWT используются — это проверка, что отправленные данные были действительно отправлены авторизованным источником

Как было продемонстрировано выше, данные внутри JWT закодированы и подписаны, обратите внимание, это не одно и тоже, что зашифрованы. Цель кодирования данных — преобразование структуры

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

Шаг 5. Проверка JWT

В нашем простом примере из 3 участников мы используем JWT, который подписан с помощью алгоритма и только сервер аутентификации и сервер приложения знают секретный ключ. Сервер приложения получает секретный ключ от сервера аутентификации во время установки аутентификационных процессов. Поскольку приложение знает секретный ключ, когда пользователь делает API-запрос с приложенным к нему токеном, приложение может выполнить тот же алгоритм подписывания к JWT, что в шаге 3. Приложение может потом проверить эту подпись, сравнивая ее со своей собственной, вычисленной хешированием. Если подписи совпадают, значит JWT валидный, т.е. пришел от проверенного источника. Если подписи не совпадают, значит что-то пошло не так — возможно, это является признаком потенциальной атаки. Таким образом, проверяя JWT, приложение добавляет доверительный слой (a layer of trust) между собой и пользователем.

✅ Получение токена через официальное приложение VK.

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

Метод будет рассматривать на примере ВКонтакте для Android. ID такой: 2890984
. Именно эту комбинацию надо подставить в ссылку.

Получится следующее:

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

Права доступа:

В примерах, которые описаны выше, параметр scope
содержит многие названия разделов социальной сети ВКонтакте: audio, photos, notify, friends. Это те разделы, которые будут открыты для приложения. Аccess_token может быть использован по-разному. ID, который вы используете, принадлежит доверенному приложению. Именно поэтому вы можете создать access_token, у которого есть все права доступа. Он становится универсальным, так что может быть использован везде.

access_token:

Последний вопрос, которого надо коснуться, так это то, как получить непосредственно сам ключ access_token

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

Уже после этого в вашей адресной строке появится необходимый ключ. Он копируется вручную: после access_token= и перед &expires_in.

Ну и закончить стоит несколькими советами:

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

Реализация

Начнем с создания класса. При инициализации будем требовать список «разрешений», к которым приложение хочет получить доступ, id этого приложения и версию API VK. Плюсом добавим несколько необязательных параметров, значение каждого из которых прояснится далее.

Как было сказано в уже упомянутой статье, нам необходимо искусно ворочать cookie и redirect’ы. Все это за нас делает библиотека с объектом класса Session. Заведем и себе такой в поле . Для парсинга html документа используется стандартный класс из модуля . Для парсера тоже написан класс (), разбирать который большого смысла нет, так как он почти полностью повторяет таковой из упомянутой статьи. Существенное отличие лишь в том, что использованный здесь позволяет изящно отклонить авторизацию приложения на последнем шаге, если вы вдруг передумали.

Поля и будут заполнены после успешной авторизации, хранит в себе результат последнего html запроса.

Пользователю библиотеки предоставим один-единственный метод – , который совершает 3 шага:

1. запрос на авторизацию приложения
2. авторизация пользователя
   2.1 введение кода-ключа в случае двух-факторной авторизации
3. подтверждение разрешения на использование

Пройдемся по каждому шагу.

Шаг 1. Запрос на авторизацию приложения

Аккуратно составляем url запроса (про параметры можно прочитать здесь), отправляем запрос и парсим полученный html.

Как получить

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

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

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

scope выбирайте в зависимости от методов, которые хотите использовать. Например, для доступа к методу

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

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

Краткая инструкция для получения токена сообщества

Заходим в настройки сообщества. (если у вас нет сообщества, значит его ):

1.
Работа с Api > 2.
Получить ключ > 3.
Скопируйте его (это ключ (токен) и есть access_token сообщества)

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

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

И так приступим. Vk api имеет много методов, но одним из основных их различий является то, что для выполнения запросов к вк апи через некоторые методы
требуется специальный ключ доступа — токен (access_token). Получить его можно создав своё приложение. Нам предлагают несколько видов приложений, но
я выбираю тип Standalone. Мне его хватает. Для начала создания приложения переходим по
ссылке

и попадаем в
следующее окно.

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

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

Процесс токен авторизации

Авторизация с помощью токена происходит следующим образом. Сначала человек запрашивает доступ к серверу или защищенному ресурсу. Запрос обычно включает в себя ввод логина и пароля. Затем сервер определяет, может ли пользователь получить доступ. После этого сервер взаимодействует с устройством: ключ, телефон, USB или что-то ещё. После проверки сервер выдает токен и отправляет пользователю. Токен находится в браузере, пока работа продолжается. Если пользователь попытается посетить другую часть сервера, токен опять связывается с ним. Доступ предоставляется или, наоборот, запрещается на основе выданного токена.

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

Что такое JSON веб-токены?

JSON Web Token (JWT) — это открытый стандарт (RFC 7519), который определяет компактный и автономный способ безопасной передачи информации между сторонами в виде объекта JSON. Эта информация может быть подтверждена благодаря цифровой подписи. JWT может быть подписан с помощью секрета (с помощью алгоритма HMAC) или иным образом, например, по схемам RSA или ECDSA.

В своей компактной форме веб-токены JSON состоят из трех частей, разделенных точками: заголовок, полезная нагрузка, подпись. Поэтому JWT выглядит обычно выглядит следующим образом: «xxxx.yyyy.zzzz».

Заголовок состоит из двух частей: типа токена, которым является JWT, и используемого алгоритма подписи, такого как HMAC SHA256 или RSA.

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

Зарегистрированная — это набор ключей, который не является обязательными, но рекомендуются для обеспечения улучшения безопасности. Например, iss — уникальный идентификатор стороны, генерирующей токен, exp  — время в формате Unix Time, определяющее момент, когда токен станет не валидным, и другие. 

Публичная информация может быть определена по желанию теми, кто использует JWT. Но они должны быть определены в реестре веб-токенов IANA JSON или определены как URI, который содержит устойчивое к коллизиям пространство имен. Частная — это пользовательская информация, созданная для обмена данными между сторонами, которые согласны их использовать. Получим вторую часть с помощью кодирования Base64Url.

Тоже не понял, что за прикол там происходит.

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

Выходные данные представляют собой три строки Base64-URL, разделенные точками, которые могут быть легко переданы в средах HTML и HTTP, будучи при этом более компактными по сравнению со стандартами на основе XML, такими как SAML.

Пример:

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

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

Рекомендации по аутентификации на основе токенов

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

Правильный веб-токен. Хотя существует целый ряд веб-токенов, ни один из них не может обеспечить ту же надежность, которую предоставляет веб-токен JSON (JWT). JWT считается открытым стандартом (RFC 7519) для передачи конфиденциальной информации между несколькими сторонами. Обмен информацией осуществляется цифровой подписью с использованием алгоритма или сопряжения открытого и закрытого ключей для обеспечения оптимальной безопасности.
Приватность.
Использование HTTPS-соединений. HTTPS-соединения были построены с использованием протоколов безопасности, включающих шифрование и сертификаты безопасности, предназначенные для защиты конфиденциальных данных

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

В случае кражи access токена, refresh куки и fingerprint’а (без примера в кодовой базе supra-api-nodejs):

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

Предложу несколько вариантов решения данной проблемы:

Хранить IP или Subnet залогиненного клиента

1. Хакер воспользовался access token’ом
2. Закончилось время жизни access token’на
3. Хакер отправляет refresh куку и fingerprint
4. Сервер проверяет IP хакера, хакер идет лесом

UX минус: нужно логинится с каждого нового IP.

Удалять все сессии в случае если refresh токен не найден

1. Хакер воспользовался access token’ом
2. Закончилось время жизни access token’на
3. Хакер отправляет refresh куку и fingerprint
4. На сервере создается новый refresh токен («от хакера»)
5. Хакер получает новую пару токенов
6. Юзер пробует отправить запрос на сервер >> обнаруживается что refresh токен не валиден
7. Сервер удаляет все сессии юзера, в последствии чего хакер больше не сможет обновлять access токен
8. Сервер создает новую сессию для пользователя

UX минус: в каждом случае когда сервер не будет находить рефреш токен — будут сбрасиватся все сессии юзера на всех устройствах.

Access token lifetime

The default lifetime of an access token varies, depending on the client application requesting the token. For example, continuous access evaluation (CAE) capable clients that negotiate CAE-aware sessions will see a long lived token lifetime (up to 28 hours). When the access token expires, the client must use the refresh token to (usually silently) acquire a new refresh token and access token.

You can adjust the lifetime of an access token to control how often the client application expires the application session, and how often it requires the user to re-authenticate (either silently or interactively). For more information, read Configurable token lifetimes.

Основы:

Аутентификация(authentication, от греч. αὐθεντικός – реальный, подлинный; от αὐθέντης – автор) — это процесс проверки учётных данных пользователя (логин/пароль). Проверка подлинности пользователя путём сравнения введённого им логина/пароля с данными сохранёнными в базе данных.

Авторизация(authorization — разрешение, уполномочивание) — это проверка прав пользователя на доступ к определенным ресурсам.

Например после аутентификации юзер sasha получает право обращатся и получать от ресурса «super.com/vip» некие данные. Во время обращения юзера sasha к ресурсу vip система авторизации проверит имеет ли право юзер обращатся к этому ресурсу (проще говоря переходить по неким разрешенным ссылкам)

1. Юзер c емайлом sasha_gmail.com успешно прошел аутентификацию
2. Сервер посмотрел в БД какая роль у юзера
3. Сервер сгенерил юзеру токен с указанной ролью
4. Юзер заходит на некий ресурс используя полученный токен
5. Сервер смотрит на права(роль) юзера в токене и соотвественно пропускает или отсекает запрос

Собственно п.5 и есть процесс авторизации.

Дабы не путатся с понятиями Authentication/Authorization можно использовать псевдонимы checkPassword/checkAccess(я так сделал в своей API)

JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок(header), набор полей (payload) и сигнатуру. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Сигнатура может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.

Пример подписанного JWT токена (после декодирования 1 и 2 блоков):

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

При попытке хакером подменить данные в header’ре или payload’е, токен cтанет не валидным, поскольку сигнатура не будет соответствовать изначальным значениям. А возможность сгенерировать новую сигнатуру у хакера отсутствует, поскольку секретный ключ для зашифровки лежит на сервере.

access token — используется для авторизации запросов и хранения дополнительной информации о пользователе (аля user_id, user_role или еще что либо, эту информацию также называет payload). Сам токен храним не в localStorage как это обычно делают, а в памяти клиентского приложения.

refresh token — выдается сервером по результам успешной аутентификации и используется для получения нового access token’a и обновления refresh token’a

Каждый токен имеет свой срок жизни, например access: 30мин, refresh: 60дней

Поскольку токены это не зашифрованная информация крайне не рекомендуется хранить в них какую либо (passwords, payment credentials, etc…)

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

Получение нового Access token по его истечении

При обмене кода авторизации на Access token вы получили и Refresh token. С его помощью вы можете получить новый Access token и продолжить работу с API.

Время жизни Refresh token — 3 месяца. Если у вас не осталось ни одного активного Refresh token, то вам потребуется заново открыть раздел «Для разработчиков» в профиле компании, получить новый код авторизации и пройти процесс обмена кода авторизации на Access token и Refresh token.

Refresh token можно использовать только один раз. После отправки его в метод и получения новой пары Access token и Refresh token старый Refresh token становится не актуальным.

Запрос на обновление Access token по Refresh token такой же, как при обмене кода авторизации, но с другими параметрами и значениями.

post

/oauth/token

получение токена доступа (по Refresh токену)

Параметры

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

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

Получение токена (access_token) api вк

Https://oauth.vk.com/authorize?client_id=&display=&redirect_uri=https://oauth.vk.com/blank.html&scope=&response_type=token&v=5.52

• client_id — ID нашего приложения, полученный раньше.
• display — вид окна, в котором будет происходить авторизация. Может быть page, popup, touch и wap
• scope — права доступа нашего приложения относительно данных пользователя. О правах поподробнее ниже.

Права приложения вк относительно заданного пользователя могут задаваться в текстовом и цифровом виде. В текстовом это будет выглядеть так
scope=friends,messages,groups . Этой строкой кода мы разрешили приложению vk доступ к друзьям, сообщениям и группам пользователя. Так же
права задаются и в цифровом виде. Для каждого правила есть битовая маска и сумма этих масок и будет разрешать приложению определённые действия. Например
право friends(+2), messages(+4096), groups(+262144), в итоге сумма битовых масок будет 266242 и код scope=266242
будет аналогом scope=friends,messages,groups

Отдельное внимание хочу уделить праву offline. Установка этого права делает получаемый нами
токен бесконечным

Если это право не задать через определённое время токен нужно будет получать снова. Подробнее о правах приложения вк можно почитать
здесь
.
В итоге давайте составим адрес для получения токена приложению с правами доступа к друзьям, сообщениям и
группам пользователя, а так же с бессмертным токеном. Id приложения пусть будет 123456. Данный адрес будет выглядеть так:

Https://oauth.vk.com/authorize?client_id=123456&display=page&redirect_uri=https://oauth.vk.com/blank.html&
scope=friends,messages,groups,offline&response_type=token&v=5.52

Подтверждаем действие и попадаем на страницу с предупреждением, из адресной строки браузера берём наш полученный токен. Это будет после #access_token= ,
код expires_in=0 говорит нам что токена (access_token) api вк бессмертный. Соответственно user_id= это id пользователя, для которого
мы получили токен.

Зайдём в настройки аккаунта во вкладку настройки приложений и увидим наше приложение.

Теперь у нас всё готово для работы с апи вконтакте.

User and application tokens

Your application may receive tokens for user (the flow usually discussed) or directly from an application (through the client credentials flow). These app-only tokens indicate that this call is coming from an application and does not have a user backing it. These tokens are handled largely the same:

• Use to see permissions that have been granted to the subject of the token.
• Use or to validate that the calling service principal is the expected one.

If your app needs to distinguish between app-only access tokens and access tokens for users, use the optional claim. By adding the claim to the field, and checking for the value , you can detect app-only access tokens. ID tokens and access tokens for users will not have the claim included.

Похожие записи:

Популярные хештеги в инстаграме: топ 2021 года Способы в тик ток смотреть новинки видео без регистрации Секреты вконтакте. упоминания и ответы других пользователей Как отметить друзей в комментариях к посту в инстаграме Как продавать в инстаграм в 2021 году: пошаговая инструкция + 10 секретных советов Какой должен быть охват в инстаграме?