Бесшовная авторизация что это
Бесшовная авторизация что это
«Единая точка входа» и «бесшовная авторизация» – базовые понятия различных стратегий интеграции сервисов
Другие интервью
«Аграрный труд требует отдачи»: ректоры аграрных вузов о ключевых изменения в отрасли
«Российское высшее образование больше не будет прежним»: ректоры об ИОТ
Старт для стартапа: опыт УрФУ
«Придать дополнительный импульс»: новый ректор ТИСБИ об истинных и ложных ориентирах высшего образования
«Все очень просто: ищем лучших людей» — проректор НИУ ВШЭ Мария Юдкевич о концепции развития университета-лидера
«Синергия образования и бизнеса»: как вузы включаются в развитие экономики региона
Портрет поколения: кто сегодня поступает в вузы? Говорим с ректорами
Портрет поколения: кто сегодня поступает в вузы? Говорим с ректорами
«Мы не хотим, чтобы наши технологии лежали на полке»: интервью с и.о. ректора ТПУ Дмитрием Седневым
«Считаю свою профессиональную жизнь счастливой»: интервью с исполняющим обязанности ректора РГППУ Валерием Дубицким
Интерес к интеграциям с электронными библиотечными системами (ЭБС) со стороны вузов поставил проблему выбора наиболее удобных для них и читателей схем аутентификации. Широко используются две схемы: «бесшовная авторизация» и «единая точка входа». Многие считают, что это одно и то же, а термины – своего рода синонимы. Но это не так, убежден ИТ-директор ИД «Лань» Станислав Тихонов. В чем разница между «бесшовной авторизацией» и «единой точкой входа», он подробно объяснил в интервью нашему изданию.
– Чем, на ваш взгляд, вызван интерес вузов к интеграциям с различными ЭБС?
– Благодаря новым Федеральным государственным образовательным стандартам (ФГОС) большинство вузов страны имеют более или менее развитую информационную систему, у каждого пользователя которой есть персональная учётная запись и доступ к электронной информационной образовательной среде (ЭИОС).
Решив задачу создания ЭИОС, вузы начали проявлять интерес к различного рода интеграциям, в частности, со сторонними электронными библиотечными системами (ЭБС).
– Какие схемы при этом используются разработчиками?
– Как правило, вузы взаимодействуют с несколькими ЭБС, предоставляя студентам, аспирантам и сотрудникам бесплатный доступ к ним. При этом очень важно, чтобы пользователи могли входить в сторонние ЭБС и переходить с одной на другую, прилагая минимум усилий. Решается эта задача с помощью внедрения технологий «единой точки» входа либо «бесшовной авторизации».
Недопонимание и неоправданные ожидания
– Почему важно тем, кто принимает решение об интеграции с той или иной ЭБС, понимать, чем «единая точка входа» отличается от «бесшовной авторизации»?
– И то, и другое является функционалом аутентификации пользователя. И в том и другом случае пользователь входит или переходит на сайт и получает права подписчика ЭБС и даже определяется как конкретный пользователь и попадает в личный кабинет.
Очень часто даже разработчики не различают понятия «единой точки входа» и «бесшовной авторизации», считая их одним и тем же. Но это совершенно не так, и дело тут не в казуистике, а в том, что в данном случае неверное понимание терминологии может повлечь за собой как минимум недопонимание, а как максимум – неверно принятые стратегические решения и неоправданные ожидания от реализованного проекта по интеграции.
Сторонний сервер как посредник
– Какой пользовательский сценарий используется при «единой точке входа»?
– Схема аутентификации «единой точки входа» позволяет использовать сервис-посредник для аутентификации на различных ресурсах. Данный сервис и будет «единой точкой входа».
При этом используется следующий пользовательский сценарий в WEB: пользователь переходит на ресурс, выбирает в окне входа вход через сервис-посредник, авторизуется в нем и попадает в личный кабинет на ресурсе. На следующем ресурсе он делает то же самое – выбирает авторизацию через посредника и входит на ресурс.
Примером такого типа аутентификации является вход через соцсети. Как правило, ВК либо Фэйсбук. В нашей библиотечной среде есть «профильный» игрок – Fedurus. Реализация авторизации от Fedurus учитывает ряд специфичных для отрасли моментов, что делает его использование удобным как для библиотек, так и для вузов. С технической точки зрения этот способ проще для внедрения и использования для всех участников.
Блокирующий фактор
– Как вы считаете, что сдерживает развитие электронной библиотечной среды?
– Большое количество логинов с паролями для различных ресурсов является основной «головной болью» всех современных пользователей. В случае с библиотечными сервисами такая ситуация может являться серьезным фактором, сдерживающим развитие отрасли. Современная и, по своей сути, удобная задумка – электронная библиотечная среда – наталкивается на то, что у пользователей при виде списка ресурсов с литературой, у каждого из которых свои учетные данные, просто опускаются руки. И посещаемость электронных библиотек страдает от этой ситуации.
«Единая точка входа» улучшает ситуацию практически на порядок – нужно авторизоваться всего на одном ресурсе, что намного более комфортно для пользователя. Но есть и более прогрессивная технология, превращающая образовательное пространство вуза в единое пространство, не ограниченное рамками авторизации.
Эта технология – «бесшовная авторизация» – избавляет пользователя от необходимости вводить логин и пароль при переходе с ресурса на ресурс. Он получает все доступы, ничего никуда не вводя.
Автоматическая аутентификация
– Какой пользовательский сценарий используется при «бесшовной авторизации»?
– На самом деле термин «бесшовная авторизация» является, скорее, обывательским фразеологизмом, отражающим происходящее с точки зрения пользователя. С технической точки зрения корректно назвать эту схему «автоматической аутентификацией».
Пользовательский сценарий для данной схемы в WEB – пользователь при переходе на ресурс опознается ресурсом, при этом сам пользователь не предпринимает сознательных действий для аутентификации. Для него это происходит прозрачно, между ресурсами нет границ, что позволяет называть такую схему «бесшовной».
«Под капотом», на самом деле, аутентификация происходит, но она производится на уровне серверов и незаметна для пользователя.
Магия бесшовной авторизации
– Каковы особенности применения автоматической аутентификации?
– Допустим, вы авторизовались в личном кабинете информационной системы вуза, нашли в каталоге какую-нибудь книгу, которая вам нужна для работы, щелкаете на ее название, совершаете обычный, с вашей точки зрения, переход на сайт ЭБС. Для вас как бы ничего не происходит, но вы уже в личном кабинете, вы уже опознаны и пользуетесь всеми благами авторизации.
При этой технологии нет посредника. Единого протокола нет. Прямое взаимодействие вуза с ЭБС осуществляется через API.
Процесс более трудоемкий для внедрения, но для пользователя использование такой схемы более удобное, он экономит свое время.
Вопрос не в финансах
– Насколько финансово обременительно для вузов внедрение той или иной схемы аутентификации?
– Основные затраты, которые несет вуз при интеграции с ЭБС, – софт и обслуживание. При использовании «бесшовной авторизации» они увеличиваются кратно количеству ЭБС. На этапе внедрения эта технология более затратная, увеличивается количество поддержки, но отсутствует абонентская плата. Для пользователя это, несомненно, более удобно.
В случае использования и «единой точки входа», и «бесшовной авторизации» финансовые затраты вузов не имеют принципиального значения, так как их сумма в общем бюджете мизерна. Но в вузе могут отсутствовать специалисты, что в конечном итоге становится определяющим фактором при выборе той или иной схемы.
Эти схемы могут быть реализованы одновременно, но одна не подразумевает наличие второй. Это рождает недопонимание. На первый взгляд, различие между «единой точкой входа» и «бесшовной авторизацией» тонкое и несущественное, но на самом деле оно является базовым и концептуально важным для определения стратегии в области интеграции сервисов.
Одновременная межсайтовая аутентификация без велосипеда
Одновременная межсайтовая аутентификация (SSO), для чего же она нужна? Допустим у нас есть, назовём его анахроничным термином «портал», с блогами, фотками, фейлами (или файлами, кому как), назовём его fail.ru (не путать с одноимённым сервисом почты на букву М), причём всё это усложнено следующими факторами:
— функционал совершенно разный;
— код написан разными людьми, с испольованием разных технологий;
— работает всё это на разных серверах в разных датацентрах и с разными базами данных;
— сервера находятся на разных доменах.
И вот у такого Кощея нам нужно будет сломать яйцо и дать пользователю возможность зайти только один раз, а потом заходить на все дружественные ресурсы не подтвеждая свою личность ещё раз.
Об этом уже достаточно много писали, причём и код в том числе. Но мы не пойдём по проторенной дороге велосипедостроения, а как настоящие инженеры возьмём готовые наработки и используем их. Способ прост, и подходит даже для такой сложной ситуации.
Далее мы рассмотрим самописные альтернативы, OpenID, OAuth, SAML, и почему всё это в общем случае не слишком хорошее решение, вопросы хранения аутенитификационных данных, а также некоторые вопросы безопасности в которые без хороших знаний самому лезть не стоит, что такое вообще межсайтовая аутентификация, развеем некоторые мифы.
Удачные решения для менее универсальных случаев
В реальной жизни бывает не так всё запущено, как в том случае, который мы рассматриваем, и порой кажется, что можно обойтись решением с выставлением общей cookie, но как только появляется внешний домен, либо пропадает общая БД для хранения сессий, решение отпадает.
Можно испльзовать вариант, описанный здесь, но в комментариях довольно много негатива по поводу iframe, javascript и прочего.
OpenID
В сети есть очень интересная заметка по поводу того, что OpenID решает проблему, которую сам и придумал. OpenID — не нужная прослойка между почтой и тем сайтом, на которым вы хотите аутентифицироваться. Например, есть у вас аккаунт на coolopenid.net, который привязан к вашей почте. При входе на целевой сайт вас отправят на coolopenid.net, там либо посмотрят cookie, если вы уже залогинены, либо спросят емейл и пароль, вы подтвердите свою личность, и далее входите на целевой сайт, как, например, foo1@coolopenid.net. Правда, не намного проще, чем подтвеждение через ссылку на электронную почту?
Для межсайтовой аутентификации OpenID не слишком удобен при большом количестве дружественных сайтов, так как пользователю придётся при входе на каждый сайт подтверждать свою личность.
OAuth
OAuth выполняет двойную задачу, аутентификацию на стороннем сайте и авторизацию на сайте-провайдере, давая пользователю возможность использовать возможности стороннего ресурса для расширения возможностей сайта-провайдера, например, заливать ссылки на фотографии в Twitter, добавлять информацию о текущем местонахождении в Facebook. Хорошее объяснение разницы здесь. Это замечательная и полезная вещь, но она призвана объединить сайты разных поставщиков, в то время как у нас всё-таки есть общее центральное хранилище имён пользователей.
Немного критики бы не помешало, но я могу лишь косвенно свидетельствовать о не слишком удачном опыте моих коллег по внедрению этого решения в инфраструктуру огромной компании с огромным количеством внутренних и внешних проектов. Ко всему прочему, количество библиотек реализующих данный протокол для различных языков программирования совсем не велико.
Читатель, наверное, уже смекнул, что я клоню к какой-то одной вещи, пытаясь убедить его в однозначности правильного выбора. И да, и нет. Хотелось описать свои метания, свой выбор и свою практику. Однозначного выбора нет, хотя для моих нужд и с моим багажом знаний CAS самое простое и всеобъемлющее решение.
CAS — это протокол, специально разработанный для одновременной межсайтовой аутентификации. У протокола есть по крайней мере две имплементации, по крайней мере одна из которых активно развивается. Выбор в пользу второй можно подкрепить тем, что нет необходимости для сервера тащить за собой пугающие многих Java зависимостей (в ущерб необходимости тащить за собой пугающие многих Ruby зависимости).
Также из плюсов можно отметить, что CAS может работать в том числе с толстыми клиентами, и даже не требует возможности установки cookies у клиентского агента. Существует достаточное количество клиентов под разные платформы для простой интеграции аутентификации пользователя через CAS.
CAS делает не много. Он не хранит данные о пользователях, он не хранит их роли, и не знает ничего о других участниках. В качестве хранилища пользователей можно использовать:
— базу данных
— LDAP/AD
— SPNEGO
— RADIUS
— сторонний сервис
— … да хоть текстовый файл
Возможно использование и с двухфакторной аутентификацией, и с usb-токенами с использованием X.509 сертификатов.
Критка и мифы
CAS — старый проект, не развивается. Текущая версия сервера — 3.4.8, последняя ревизия протокола — 2005 год.
Последнее обновление — 9 ноября этого года.
Видимо, протокол вполне реализует необходимый для нужд SSO функционал, и дальнейшее развитие не требуется, как, например, протокол HTTP не обновлялся с июня 1999го года.
CAS — непопулярный проект. Несмотря на то, что ему не один год, он так и не получил признания — практически никакого. Тот факт, что используют 120 школ, колледжей и университетов И БОЛЬШЕ НИКТО, говорит о том, что никто другой и не может его использовать.
Не факт, что все, кто используют эту одну из имплементаций, показаны по этой ссылке.
CAS разрабатывается одной фирмой под свою конкретную задачу. Программисты, которые написали CAS занимаются тем, что делают свой образовательный портал.
Предположу, что эти люди не такие меценаты, чтобы делать софт под чужую общую задачу. А раз уж сделано, так и не жалко в общий доступ отдать.
CAS — это частная разработка, не имеющая реальных историй успеха нигде, кроме весьма узкой области применения (университеты, контроль за студентами) и нигде, кроме как для чужого решения (uPortal).
Можно сказать то же самое и о других упоминавшихся в обсуждаемом топике решениях. Хотя, возможно, я чего-то не знаю.
Удивительно маленькое коммьюнити. Если мы поищем в сети типичную ошибку общего свойства, то мы найдем всего 100 отзывов.
Ищете правильно. About 3,210,000 results (0.21 seconds). Если поставить в кавычки, то есть искать точное совпадение — 7.5 тысяч.
Удивительно малое число реализаций. Собственно, есть ТОЛЬКО ДВЕ имплементации CAS сервера. А сколько СОТЕН имплементаций OpenID провайдеров написано?
OpenID — не альтернатива, как описано выше. Количество реализаций не говорит о простоте интеграции.
Принцип работы
Первый вход.
1. Пользователь заходит на страницу, доступ к которой есть только у зарегистрированных пользователей.
2. Сайт делает HTTP переадресацию на CAS-сервер.
3. Пользователь вводит логин и пароль.
4. CAS через нужный адаптер определяет правильность логина и пароля.
5. В случае успешной аутентификации CAS-сервер переадресует пользователя на страницу, указанную сайтом как страница успешного входа, прикрепляя в запросе служебный проверочный тикет.
6. Сайт делает внутренний межсайтовый HTTP запрос к CAS-серверу на проверку тикета.
7. Пользователь авторизован, можно связывать его session cookie с логином, полученным от CAS-сервера.
Повторный вход (например, на сайт 2).
1. Пользователь заходит на страницу, доступ к которой есть только у зарегистрированных пользователей.
2. Сайт делает HTTP переадресацию на CAS-сервер.
3. CAS-сервер видит cookie пользователя и переадресует пользователя на страницу, указанную сайтом как страница успешного входа, прикрепляя в запросе служебный проверочный тикет.
4. Сайт делает внутренний межсайтовый HTTP запрос к CAS-серверу на проверку тикета.
5. Пользователь авторизован, можно связывать его session cookie с логином, полученным от CAS-сервера.
Такой способ закрывает достаточное количество дыр в безопасности.
Установка
3. rubycas-server
git clone git@github.com:rubycas/rubycas-server.git
cd rubycas-server
bundle install
4. Устанавливаем thin (веб-сервер) и запускаемся
gem install thin
thin start
Это самый простой, но не самый лучший вариант. Стоит рассмотреть запуск под unicorn и nginx.
Использование на клиенте
На примере Ruby/Rack/Sinatra приложения:
Gemfile:
…
gem ‘oa-enterprise’, :require => ‘omniauth/enterprise’
…
Приложение:
…
set :login_page, «/auth/cas»
Аутентификация и авторизация в микросервисных приложениях
Автор: Вячеслав Михайлов, 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: