Sso авторизация что это

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

SSO (Single Sign-On)

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

Содержание

Общая схема систем единого входа

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

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

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

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

Основные достоинства и недостатки SSO

Методы SSO

Технология единого входа включает в себя следующие методы:

Основные преимущества SSO

Протоколы, обеспечивающие технологию единого входа

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

Протоколы семейства WS-

Данный протокол основывается на стандартах WS-Security и WS-Trust и описан в спецификации WS-Federation Passive Requestor Profile, в которой представлены механизмы для запроса, обмена и выдачи маркера безопасности в ситуации с пассивным клиентом. Определение «пассивный клиент» подразумевает наличие на компьютере пользователя только веб-браузера, так как взаимодействие между пользователем, Центр Идентификации и Целевое Приложение (веб-сервер, предоставляющий ресурсы) происходит в пределах функциональности базы HTTP (методы GET, POST, перенаправления и cookies). Схема протокола имеет следующий вид:

С учетом требований, описанных в спецификации WS-Federation Passive Requestor Profile, протоколом поддерживаются следующие форматы маркеров безопасности:

Протокол SAML

SAML (англ. security assertion markup language — язык разметки декларации безопасности) — язык разметки, основанный на языке XML. Открытый стандарт обмена данными аутентификации и авторизации между участниками, в частности, между поставщиком учётных записей (англ. identity provider) и поставщиком сервиса (англ. service provider). SAML — продукт OASIS, разработанный Техническим комитетом безопасности сервиcов. SAML создан в 2001 году; последнее значимое обновление SAML было опубликовано в 2005 году, но расширения протокола постоянно выпускались через дополнительные, опциональные стандарты.

Одной из важных проблем, которую пытается решить SAML, является обеспечение сквозной аутентификации при работе через Web-браузер. Использование SAML в качестве технологии единого входа на уровне сети (intranet) распространено (например, с использованием cookies), но расширение за пределы частной сети (intranet) было проблематично и привело к созданию несовместимых запатентованных технологий (другой, более современный подход обеспечения SSO — это протокол OpenID)

Протокол OpenID

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

Аутентификация посредством OpenID [FH07] обеспечивает возможность подтвердить, что пользователь обладает идентификатором без запроса доверенной стороной у пользователя его идентификационных данных, таких как пароль или адрес электронной почты. OpenID – децентрализованный протокол, пользователь может выбрать идентификатор какого провайдера OpenID предоставить. Для поддержки данного протокола требуется только JavaScript или современный веб-браузер. OpenID использует только стандарты HTTPS, то есть не требует никаких специальных возможностей клиентского программного обеспечения. Основными элементами процесса аутентификации являются:

Идентификатор OpenID – это строка, которая является уникальной для каждого пользователя. Один идентификатор не может принадлежать более чем одному пользователю. Различают следующие два вида идентификаторов:

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

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

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

Протокол OAuth

Схема протокола имеет следующий вид:

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

Источник

SSO Single SignOn — однократная аутентификация

Технология аутентификации

Аутентификация – это процесс, который состоит из двух этапов:

Аутентификация может быть однофакторной, двухфакторной (2FA) или многофакторной. Последний вариант – более надежный, так как подразумевает не только ввод логина и пароля, но и дополнительную аутентификацию. Один из примеров – SMS или получение push-уведомления в мобильном приложении.

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

Технология единого входа в систему

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

Единый вход в систему (Single SignOn, SSO) позволяет пользователям безопасно аутентифицироваться в нескольких приложениях и на веб-сайтах, войдя в систему только один раз с одним набором учетных данных. При использовании единого входа пользователю достаточно ввести свои учетные данные только один раз на одной странице, чтобы получить доступ ко всем своим приложениям SaaS.

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

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

Возможности технологии единого входа

Защита с помощью пароля является популярной, но не идеальной, поэтому бизнесам приходится использовать дополнительные средства. SSO – это мощный и эффективный инструмент для упрощения работы сотрудников с web-сайтами и приложениями.

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

От чего защищает SSO Single SignON? Технология единого входа предотвращает утечку паролей от внутренних ресурсов компании, а также делает невозможным неразрешенное изменение данных.

Благодаря SSO вход в приложения под чужими учетными записями становится невозможным. А предотвращение утечки конфиденциальных данных – это главная задача службы безопасности. Утечка пользовательских и клиентских данных влечет за собой огромный репутационный урон для компании, вне зависимости от того, насколько качественный продукт или услугу она предлагает. Помимо этого, SSO – это просто, удобно и фактически незаметно для сотрудников. Они тратят меньше времени, при этом значительно повышается уровень комфорта.

SSO защищает:

Преимущества технологии единого входа

Особенности технологии единого доступа

Несмотря на простоту и высокую степень защиты, SSO обеспечивает максимальную защиту только в том случае, когда инженеры корректно ее настраивают, c чем инженеры Cloud Networks смогут помочь.

SSO имеет следующие особенности:

Среди компаний, которые применяют SSO, пользуясь нашими услугами, — ВТБ, X5 Retail Group, СУЭК, Ростелеком, TatNeft, РОСНАНО, СОГАЗ и многие другие. Благодаря технологии единого входа повышается безопасность, а высвобожденные временные ресурсы направляются на решение профильных задач.

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

Источник

Как работает single sign-on (технология единого входа)?

Что такое single sign-on?

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

Как работает SSO?

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

Порядок авторизации обычно выглядит следующим образом:

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

Что такое токен в контексте SSO?

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

Является ли технология SSO безопасной?

Ответом на этот вопрос будет «в зависимости от ситуации».

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

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

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

Как внедрить SSO?

Особенности внедрения SSO могут отличаться с учетом того, с каким именно решением SSO вы работаете. Но вне зависимости от способа, вам нужно точно знать какие цели вы преследуете. Убедитесь, что вы ответили на следующие вопросы:

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On — что означает “такой же/одинаковый вход”, а не “единый вход” (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

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

В чем разница между программным обеспечением единого входа и решением SSO?

Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) — это характеристика/фича, доступная внутри архитектуры FIM.

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

OpenID Connect (OIDC) — это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) — это открытый стандарт, который также разработан для обеспечения функциональности SSO.

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Service Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) — это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) — это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа “Software as a Service” (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.

Источник

Аутентификация и авторизация в микросервисных приложениях

Автор: Вячеслав Михайлов, Solutions Architect

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

Что такое аутентификация?

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

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

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

Способы аутентификации

При использовании HTTP-протокола простейший способ аутентификации — Basic access authentication. В принципе этот протокол устарел и уже редко используется в интернете, особенно в незащищенных соединениях, но еще сохраняется во внутрикорпоративных системах, просто потому что некоторые из них созданы достаточно давно. Стоит разобраться, как он работает.

HTTP Basic Authentication

Первым, что при обращении к защищенному ресурсу сервер выдаст пользователю, не имеющему доступа, будет ошибка 401 Unauthorized. При этом ответ также содержит информацию о типе аутентификации (в нашем случае – Basic), который он может принимать, и контекст, в рамках которого эта аутентификация действует (Realm). Пользователь вводит логин и пароль, они упаковываются в Base64 и отправляются на сервер для проверки. Здесь существуют различные опасности. Самая распространенная — угроза man-in-the-middle attack, или атаки посредника, в ходе которой при использовании незащищенного соединения учетные данные могут перехватить злоумышленники в момент передачи от клиента к серверу или обратно.

HTTP Digest Authentication

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

Forms Authentication

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

Token Authentication

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

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

OAuth2 & Open ID Connect

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

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

В 2006 году в ходе работы над реализацией протокола Open ID для Twitter обнаружилась потребность в новом открытом протоколе авторизации. В 2007 инженеры Google и AOL начали совместную работу над ним, а в 2009 Twitter предложил своим пользователям решение, делегировавшее сторонним сервисам доступ к аккаунтам и основанное на протоколе OAuth. Три года спустя была опубликована новая версия — OAuth 2, упростившая разработку клиентских приложений и получившая целый ряд новых возможностей, среди которых оказалось и обновление токена без участия пользователя. Многие сервисы начали использовать этот протокол еще до его официального утверждения.

Разбираемся детально ху из ху

OpenID 1.0 (2006) & OpenID 2.0 (2007) позволяли приложению(арб) запрашивать у доверенного сервера (authority) проверку пользователя(user). Отличия между версиями для нас несущественны.

Взгляд сверху

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

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

В качестве реализации мы рассматриваем протокол OAuth2. В принципе, существуют и другие, например, Kerberos, успешно взаимодействующий с Windows, но в случае гетерогенной сети, в которой существуют компьютеры, использующие и Windows-, и Mac-, и UNIX-системы, использовать проприетарные протоколы зачастую неудобно. Тем более, это касается случаев, когда доступ к вашим сервисам осуществляется через веб — здесь OAuth2 оказывается лучшим кандидатом.

На рисунке выше показано, какие именно протоколы используются при каждом типе взаимодействия.

Как мы знаем из раздела «разбираемся детально ху из ху», OpenID Сonnect нужен, чтобы получить у пользователя его учетные данные и проверить их. OAuth 2.0 нужен, чтобы получать токены доступа и с ними обращаться к ресурсам.

Терминология OAuth2 & OpenID Connect

Сервис выдачи токенов

Open ID Connect Provider — важнейший объект всей конструкции централизованного сервиса аутентификации, он также может называться Security Token Service, Identity Provider authorization server и т. д. Различные источники называют его по-разному, но по смыслу это сервис, который выдает токены клиентам.

Клиент

Client — устройство или программа (браузер, приложение), которым требуется либо токен для аутентификации пользователя, либо токен для доступа к какому-то ресурсу (подразумевается, что данный ресурс «знаком» с тем конкретным «Security Token Service» у которого клиент запрашивает токен для доступа).

Пользователь

User — собственно конечный пользователь — человек.

Область (scope)

Scope — идентификатор ресурса, к которому клиент хочет получить доступ. Список scope посылается в адрес сервиса выдачи токенов в составе запроса на аутентификацию.

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

Scopes бывают двух видов:

Запрос на аутентификацию

Authentication/Token Request — процесс запроса аутентификации.

Токен личности

Identity Token — подтверждение аутентификации. Этот токен содержит минимальный набор информации о пользователе.

Токен доступа

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

Токен обновления

Refresh Token — токен, по которому STS вернет новый Access Token. В зависимости от режима работы, Refresh Token может быть многоразовым и одноразовым. В случае с одноразовым токеном, при запросе нового Access Token будет также сформирован готовый Refresh Token, который следует использовать при повторном обновлении. Очевидно, что одноразовые токены более безопасны.

Более подробно о составе токенов в разделе «структура токена».

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

При обращении пользователя к клиенту, тот перенаправляет пользователя на Open ID Connect Provider, который запрашивает у пользователя логин и пароль. В случае успешного прохождения проверки параметров аутентификации он возвращает назад identity token и access token, с которыми пользователь может обращаться к защищенному ресурсу.

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

Формат

В реализации OAuth2 используется так называемый jwt-токен, который состоит из трех частей. Допустим, при обращении к Identity provider вы отправляете логин/пароль и в ответ получаете токен. Он будет включать в себя: Header (заголовок), Payload (контент) и Signature (подпись). На сайте jwt.io его можно декодировать и посмотреть содержимое формате JSON. На этом сайте вы также найдете описание правил формирования jwt-токенов.

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

Кроме identity tokens, есть еще и аccess tokens, которые содержат информацию о выданных пользователю клеймах. Срок действия access token достаточно короткий, потому что его хищение может обеспечить несанкционированный доступ к ресурсу. Т. е. злоумышленник, если ему удастся заполучить токен этого типа, доступ получит на очень непродолжительное время. Для получения нового access token используется refresh token, который обычно не фигурирует в незащищенных средах, в частности в режиме доступа из браузера он вообще не используется. Какие именно токены будут возвращены клиенту в процессе аутентификации, разберемся в следующей части.

Основные поля

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

Заключение первой части

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

Минимальная реализация интеграция Identity Server в ваше приложение выглядит так:

Минимальная реализация интеграции веб-клиента с Identity Server:

Минимальная реализация интеграции веб-API с Identity Server:

Источник