Microsoft paid connectivity wifi access token что это

Обновлено: 06.07.2024

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

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

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

Аутентификация на основе сессий

Чтобы избавиться от этого неудобства, придумали аутентификацию на основе сессий/кук, с помощью которых реализовали отслеживание состояний (stateful). Это означает, что аутентификационная запись или сессия должны храниться и на сервере, и на клиенте. Сервер должен отслеживать активные сессии в базе данных или памяти, а на фронтенде создаётся кука, в которой хранится идентификатор сессии. Это аутентификация на основе куки, самая распространённый и широко известный метод, используемый уже давно.

Процедура аутентификации на основе сессий:

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

У этого метода несколько недостатков.

При каждой аутентификации пользователя сервер должен создавать у себя запись. Обычно она хранится в памяти, и при большом количестве пользователей есть вероятность слишком высокой нагрузки на сервер.
Поскольку сессии хранятся в памяти, масштабировать не так просто. Если вы многократно реплицируете сервер, то на все новые серверы придётся реплицировать и все пользовательские сессии. Это усложняет масштабирование. (Я считал, этого можно избежать, если иметь выделенный сервер для управления сессиями, но это сложно реализовать, да и не всегда возможно.)

Аутентификация на основе токенов

Аутентификация на основе токенов в последние годы стала очень популярна из-за распространения одностраничных приложений, веб-API и интернета вещей. Чаще всего в качестве токенов используются Json Web Tokens (JWT) . Хотя реализации бывают разные, но токены JWT превратились в стандарт де-факто.

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

Процедура аутентификации на основе токенов:

Пользователь вводит имя и пароль.
Сервер проверяет их и возвращает токен (JWT), который может содержать метаданные вроде user_id, разрешений и т. д.
Токен хранится на клиентской стороне, чаще всего в локальном хранилище, но может лежать и в хранилище сессий или кук.
Последующие запросы к серверу обычно содержат этот токен в качестве дополнительного заголовка авторизации в виде Bearer . Ещё токен может пересылаться в теле POST-запроса и даже как параметр запроса.
Сервер расшифровывает JWT, если токен верный, сервер обрабатывает запрос.
Когда пользователь выходит из системы, токен на клиентской стороне уничтожается, с сервером взаимодействовать не нужно.

У метода есть ряд преимуществ:

Главное преимущество: поскольку метод никак не оперирует состояниями, серверу не нужно хранить записи с пользовательскими токенами или сессиями. Каждый токен самодостаточен, содержит все необходимые для проверки данные, а также передаёт затребованную пользовательскую информацию. Поэтому токены не усложняют масштабирование.
В куках вы просто храните ID пользовательских сессий, а JWT позволяет хранить метаданные любого типа, если это корректный JSON.
При использовании кук бэкенд должен выполнять поиск по традиционной SQL-базе или NoSQL-альтернативе, и обмен данными наверняка длится дольше, чем расшифровка токена. Кроме того, раз вы можете хранить внутри JWT дополнительные данные вроде пользовательских разрешений, то можете сэкономить и дополнительные обращения поисковые запросы на получение и обработку данных.
Допустим, у вас есть API-ресурс /api/orders, который возвращает последние созданные приложением заказы, но просматривать их могут только пользователи категории админов. Если вы используете куки, то, сделав запрос, вы генерируете одно обращение к базе данных для проверки сессии, ещё одно обращение — для получения пользовательских данных и проверки, относится ли пользователь к админам, и третье обращение — для получения данных.
А если вы применяете JWT, то можете хранить пользовательскую категорию уже в токене. Когда сервер запросит его и расшифрует, вы можете сделать одно обращение к базе данных, чтобы получить нужные заказы.
У использования кук на мобильных платформах есть много ограничений и особенностей. А токены сильно проще реализовать на iOS и Android. К тому же токены проще реализовать для приложений и сервисов интернета вещей, в которых не предусмотрено хранение кук.

Благодаря всему этому аутентификация на основе токенов сегодня набирает популярность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Единая точка входа (Single Sign On, SSO)

Обращали внимание, что, когда логинишься в браузере в каком-нибудь Google-сервисе, например Gmail, а потом идёшь на Youtube или иной Google-сервис, там не приходится логиниться? Ты автомагически получаешь доступ ко всем сервисам компании. Впечатляет, верно? Ведь хотя Gmail и Youtube — это сервисы Google, но всё же раздельные продукты. Как они аутентифицируют пользователя во всех продуктах после единственного входа?

Этот метод называется единой точкой входа (Single Sign On, SSO).

Реализовать его можно по-разному. Например, использовать центральный сервис для оркестрации единого входа между несколькими клиентами. В случае с Google этот сервис называется Google Accounts . Когда пользователь логинится, Google Accounts создаёт куку, которая сохраняется за пользователем, когда тот ходит по принадлежащим компании сервисам. Как это работает:

Пользователь входит в один из сервисов Google.
Пользователь получает сгенерированную в Google Accounts куку.
Пользователь идёт в другой продукт Google.
Пользователь снова перенаправляется в Google Accounts.
Google Accounts видит, что пользователю уже присвоена кука, и перенаправляет пользователя в запрошенный продукт.

Очень простое описание единой точки входа: пользователь входит один раз и получает доступ ко всем системам без необходимости входить в каждую из них. В этой процедуре используется три сущности, доверяющие другу прямо и косвенно. Пользователь вводит пароль (или аутентифицируется иначе) у поставщика идентификационной информации (identity provider, IDP), чтобы получить доступ к поставщику услуги (service provider (SP). Пользователь доверяет IDP, и SP доверяет IDP, так что SP может доверять пользователю.

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

Аутентификация в соцсетях

Уверен, эта картинка знакома всем:

Это часто называют аутентификацией в соцсетях (Social sign-in) или социальным логином (Social Login). Вы можете аутентифицировать пользователей по их аккаунтам в соцсетях. Тогда пользователям не придётся регистрироваться отдельно в вашем приложении.

Формально социальный логин — это не отдельный метод аутентификации. Это разновидность единой точки входа с упрощением процесса регистрации/входа пользователя в ваше приложение.

Лучшее из двух миров

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

Как использовать

Как разработчик вы должны разбираться в работе этого метода аутентификации. Большинство соцсетей в качестве механизма аутентификации используют авторизацию через OAuth2 (некоторые используют OAuth1, например Twitter). Разберёмся, что такое OAuth. Соцсеть — это сервер ресурсов , ваше приложение — клиент , а пытающийся войти в ваше приложение пользователь — владелец ресурса . Ресурсом называется пользовательский профиль / информация для аутентификации. Когда пользователь хочет войти в ваше приложение, оно перенаправляет пользователя в соцсеть для аутентификации (обычно это всплывающее окно с URL’ом соцсети). После успешной аутентификации пользователь должен дать вашему приложению разрешение на доступ к своему профилю из соцсети. Затем соцсеть возвращает пользователя обратно в ваше приложение, но уже с токеном доступа. В следующий раз приложение возьмёт этот токен и запросит у соцсети информацию из пользовательского профиля. Так работает OAuth (ради простоты я опустил технические подробности).

Для реализации такого механизма вам может понадобиться зарегистрировать своё приложение в разных соцсетях. Вам дадут app_id и другие ключи для конфигурирования подключения к соцсетям. Также есть несколько популярных библиотек/пакетов (вроде Passport , Laravel Socialite и т. д.), которые помогут упростить процедуру и избавят от излишней возни.

Двухфакторная аутентификация (2FA)

Двухфакторная аутентификация (2FA) улучшает безопасность доступа за счёт использования двух методов (также называемых факторами) проверки личности пользователя. Это разновидность многофакторной аутентификации . Наверное, вам не приходило в голову, но в банкоматах вы проходите двухфакторную аутентификацию: на вашей банковской карте должна быть записана правильная информация, и в дополнение к этому вы вводите PIN. Если кто-то украдёт вашу карту, то без кода он не сможет ею воспользоваться. (Не факт! — Примеч. пер.) То есть в системе двухфакторной аутентификации пользователь получает доступ только после того, как предоставит несколько отдельных частей информации.

На хабре уже писали про 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 — хороший выбор.

Клиенты должны обрабатывать маркеры как непрозрачные строки, так как их содержимое предназначено только для ресурса (интерфейса API). Только для проверки и отладки разработчики могут декодировать JWT через jwt.ms или другой аналогичный сайт. Но имейте в виду, что маркеры, которые вы получаете для API Майкрософт, не обязательно являются маркерами JWT и вы не всегда сможете их декодировать.

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

В разделах статьи ниже показано, как API может проверять и использовать утверждения в маркере доступа.

Форматы маркеров и владение

Версии 1.0 и 2.0

На платформе удостоверений Майкрософт доступны две версии маркеров доступа: 1.0 и 2.0. Эти версии определяют, какие утверждения входят в маркер. Это гарантирует, что веб-API сможет управлять тем, как выглядят маркеры. При регистрации веб-API по умолчанию выбирается версия 1.0 для приложений, предназначенных только для Azure AD, и версия 2.0 для приложений, которые поддерживают учетные записи потребителей. Это можно контролировать в манифесте приложения с помощью параметра accessTokenAcceptedVersion , где null и 1 соответствуют маркерам версии 1.0, а 2 — маркерам версии 2.0.

Для какого приложения предназначен маркер?

В запросе маркера доступа участвуют две стороны: клиент, который запрашивает маркер, и ресурс (API), который его принимает при вызове API. Утверждение aud в маркере указывает на ресурс, для которого предназначен это маркер (его аудиторию). Клиенты используют маркер, но не должны распознавать его или пытаться проанализировать. Ресурсы принимают маркер.

Платформа удостоверений Майкрософт поддерживает выпуск любой версии маркера из любой конечной точки — они не связаны между собой. Если для параметра ресурса accessTokenAcceptedVersion задано значение 2 , то клиент, который вызывает конечную точку версии 1.0 для получения маркера для этого API, получит маркер доступа версии 2.0. Ресурсы всегда владеют своими маркерами с их утверждением aud и являются единственными приложениями, которые могут изменять данные этих маркеров. Поэтому изменение необязательных утверждений маркера доступа для клиента не изменяет маркер доступа, полученный при запросе для user.read , который принадлежит ресурсу Microsoft Graph.

Примеры маркеров

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

Версия 1.0

Изучите этот маркер версии 1.0 на сайте jwt.ms.

Версия 2.0

Изучите этот маркер версии 2.0 на сайте jwt.ms.

Утверждения в маркерах доступа

JWT (веб-маркеры JSON) состоят из трех частей.

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

Эти части разделяются точками ( . ) и кодируются в Base64 по отдельности.

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

Некоторые утверждения помогают Azure AD защищать маркеры от повторного использования. Они отмечаются в описании как Opaque (Непрозрачные), то есть недоступные для широкого использования. Такие утверждения могут присутствовать или отсутствовать в маркере, и в любой момент без предварительного уведомления могут быть добавлены новые.

Утверждения заголовка

Утверждение	Формат	Описание
typ	Строка — всегда JWT	Указывает, что маркер имеет тип JWT.
alg	Строка	Обозначает алгоритм, с помощью которого был подписан маркер, например RS256.
kid	Строка	Указывает отпечаток открытого ключа, который можно использовать для проверки подписи маркера. Выпускаются в маркерах доступа версий 1.0 и 2.0.
x5t	Строка	Действует и указывается точно так же, как kid . x5t — устаревшее утверждение, которое выпускается только в маркерах доступа версии 1.0 для обеспечения совместимости.

Утверждения полезных данных

Утверждение избытка групп

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

Базовые утверждения в версии 1.0

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

Утверждение amr

Проверку подлинности удостоверений Майкрософт можно выполнять несколькими способами, с учетом особенностей приложения. Утверждение amr представляет собой массив с несколькими элементами, например ["mfa", "rsa", "pwd"] , и используется при аутентификации с помощью пароля и приложения Authenticator.

Время существования маркера доступа

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

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

Проверка маркеров

Не все приложения должны проверять маркеры. Такая проверка должна происходить только в определенных сценариях:

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

API-интерфейсы и веб-приложения должны проверять только маркеры c утверждением aud , которое соответствует приложению. Другие ресурсы могут иметь собственные правила проверки маркеров. Например, маркеры для Microsoft Graph не будут проверяться согласно этим правилам, так как они представляют собой собственный формат. Проверка и прием маркеров, которые предназначены для другого ресурса, являются примером проблемы неумышленного посредника (confused deputy).

Ниже предоставлена информация для тех, кто хочет разобраться в базовых процессах. ПО промежуточного слоя Azure AD содержит встроенные возможности для проверки маркеров доступа. Вы можете найти пример для выбранного вами языка в нашем наборе примеров. Для проверки JWT доступны несколько сторонних библиотек с открытым кодом. Среди них вы найдете как минимум один вариант практически для каждой платформы и языка. Дополнительные сведения и примеры кода см. в статье о библиотеках проверки подлинности в Azure AD.

Проверка подписи

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

Маркеры, выдаваемые Azure AD, подписываются при помощи стандартных отраслевых алгоритмов асимметричного шифрования, таких как RS256. Заголовок JWT содержит сведения о ключе и методе шифрования, используемых для подписания маркера.

Утверждение alg определяет алгоритм, использованный для подписания маркера, а утверждение kid — конкретный открытый ключ, использованный для проверки маркера.

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

Данные ключа подписи, необходимые для проверки подписи, можно найти в документе метаданных OpenID Connect по ссылке:

Попробуйте ввести этот URL-адрес в браузере.

Это объект в формате JSON, который содержит несколько полезных блоков информации, таких как расположение различных конечных точек, необходимых для проверки подлинности OpenID Connect.
Он включает jwks_uri с информацией о расположении набора открытых ключей, которые соответствуют закрытым ключам, используемым для подписания маркеров. Документ веб-ключа JSON (JWK), который находится в jwks_uri , содержит все сведения об открытых ключах, используемые в конкретный момент времени. Формат JWK описан в RFC 7517. Приложение может использовать утверждение kid в заголовке маркера JWT, чтобы выбрать открытый ключ в этом документе, который соответствует закрытому ключу, использованному для подписания определенного маркера. Затем оно может выполнить проверку подписи с использованием правильного общедоступного ключа и указанного алгоритма.

Мы рекомендуем использовать утверждение kid для проверки маркера. Маркеры версии 1.0 содержат утверждения x5t и kid , а маркеры версии 2.0 — только утверждение kid .

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

Авторизация на основе утверждений

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

Используйте утверждение aud , чтобы убедиться, что пользователь собирался вызвать ваше приложение. Если в утверждении aud отсутствует идентификатор ресурса, отклоните его.
Используйте утверждение scp , чтобы убедиться, что пользователь предоставил вызывающему приложению разрешение на вызов API.
Используйте утверждения roles и wids , чтобы убедиться, что у самого пользователя есть разрешение на вызов API. Например, администратор может иметь разрешение на запись в ваш API, но у обычного пользователя такого права может не быть.
С помощью утверждения appid убедитесь, что вызывающий клиент имеет право вызывать API.
Убедитесь, что tid обозначает клиент, который имеет право вызывать этот API.
С помощью утверждения amr проверьте, прошел ли пользователь многофакторную проверку подлинности. Это требование нужно предварительно применять при помощи Условного доступа.

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

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

Маркеры пользователя и приложения

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

Используйте roles , чтобы просмотреть разрешения, предоставленные субъекту маркера.
Используйте oid или sub , чтобы проверить, является ли вызывающий субъект-служба ожидаемым.

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

Отзыв маркеров

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

Время ожидания для маркеров

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

MaxInactiveTime: если маркер обновления не использовался в течение времени, указанного в параметре MaxInactiveTime, этот маркер обновления считается недопустимым.
MaxSessionAge: если MaxAgeSessionMultiFactor или MaxAgeSessionSingleFactor имеют значения, отличные от значений по умолчанию (Until-revoked), то по истечении периода, заданного в параметре MaxAgeSession*, потребуется повторная аутентификация.

Примеры:

Для клиента параметр MaxInactiveTime имеет значение 5 дней. Пользователь провел неделю в отпуске, а значит, в течение 7 дней от него не поступало запросов к Azure AD на получение маркеров. При следующем запросе маркера от этого пользователя выяснится, что маркер обновления уже отозван, а значит, учетные данные нужно ввести заново.
Для важных приложений параметр MaxAgeSessionSingleFactor имеет значение 1 день. Если пользователь выполнит вход в понедельник, то по истечении 25 часов (во вторник) ему придется пройти проверку подлинности повторно.

Запрет доступа

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

Изменение	Файл cookie на основе пароля	Маркер на основе пароля	Файл cookie без использования пароля	Маркер без использования пароля	Конфиденциальный маркер клиента
Срок действия пароля	Остается активным	Остается активным	Остается активным	Остается активным	Остается активным
Пароль изменен пользователем	Отменен	Отменен	Остается активным	Остается активным	Остается активным
Пользователь выполняет SSPR	Отменен	Отменен	Остается активным	Остается активным	Остается активным
Администратор сбрасывает пароль	Отменен	Отменен	Остается активным	Остается активным	Остается активным
Пользователь отменяет свои маркеры обновления с помощью PowerShell	Отменен	Отменен	Отменен	Отменен	Отменен
Администратор отменяет все маркеры обновления для пользователя с помощью PowerShell	Отменен	Отменен	Отменен	Отменен	Отменен
Единый выход (v 1.0, v 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, где вы получите готовую базу навыков и необходимую поддержку. Кстати, на курсе большое внимание уделяется безопасности как клиентской, так и серверной части веб-приложения.

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

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