Федеративная идентификация: SAML, OAuth и OpenID Connect
Узнайте, как SSO, утверждения SAML, сценарии OAuth 2.0 и токены OpenID Connect позволяют пользователям безопасно проходить аутентификацию один раз в разных приложениях.
«Федеративная идентификация: SAML, OAuth и OpenID Connect» — бесплатный урок Security+ Academy на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Security+ Academy, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Security+ Academy содержит 4 уроков всего.
Проблема идентификации между доменами
В современных организациях сотрудникам требуется доступ к десяткам приложений — облачным приложениям, инструментам SaaS, порталам партнёров и внутренним системам, каждое из которых может обслуживаться отдельной организацией. Создание и управление отдельными учётными записями для каждого приложения небезопасно (приводит к чрезмерному распространению учётных данных) и неэффективно. Федеративная идентификация решает эту проблему, позволяя поставщику удостоверений (IdP) — доверенному авторитетному источнику данных об идентичности — аутентифицировать пользователей и передавать подтверждённую идентичность поставщикам услуг (SP) между организационными границами. Пользователи проходят аутентификацию один раз и получают доступ к нескольким системам без повторного ввода учётных данных.
Основы единого входа (SSO)
Единый вход (SSO) позволяет пользователям пройти аутентификацию один раз и получать доступ к нескольким приложениям в рамках сеанса без повторной аутентификации. Пользователь входит через поставщика удостоверений (корпоративный Active Directory, Okta, Azure AD), получает маркер сеанса или утверждение и предъявляет этот маркер каждому посещаемому поставщику услуг. SSO повышает безопасность, поскольку уменьшает число паролей, которыми пользователям приходится управлять (снижая их повторное использование), позволяет централизованно применять политики аутентификации и обеспечивает немедленный отзыв доступа во всех интегрированных приложениях при отключении учётной записи на уровне IdP.
SAML 2.0: федерация на основе XML
SAML (язык разметки утверждений безопасности) 2.0 — это открытый стандарт на основе XML для обмена данными аутентификации и авторизации между поставщиками удостоверений и поставщиками услуг. Поток SAML выглядит так: (1) пользователь обращается к поставщику услуг (например, Salesforce); (2) SP перенаправляет его к поставщику удостоверений (например, Okta); (3) пользователь проходит аутентификацию в IdP; (4) IdP выпускает подписанное XML-утверждение SAML, содержащее идентичность и атрибуты пользователя; (5) утверждение возвращается в SP; (6) SP проверяет подпись утверждения с помощью открытого ключа IdP и предоставляет доступ. SAML широко применяется для корпоративного SSO в веб-приложениях.
<!-- Simplified SAML Assertion structure -->
<saml:Assertion xmlns:saml='urn:oasis:names:tc:SAML:2.0:assertion'
IssueInstant='2026-06-21T10:00:00Z'
ID='_abc123'>
<saml:Issuer>https://idp.company.com</saml:Issuer>
<saml:Subject>
<saml:NameID>alice@company.com</saml:NameID>
</saml:Subject>
<saml:Conditions NotBefore='2026-06-21T10:00:00Z'
NotOnOrAfter='2026-06-21T10:05:00Z'/>
<saml:AttributeStatement>
<saml:Attribute Name='groups'>
<saml:AttributeValue>Sales</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<!-- Signature verifies IdP signed this assertion -->
</saml:Assertion>Роли SAML: IdP, SP и субъект
В федерации SAML участвуют три стороны. Субъект — это пользователь (или система), запрашивающий доступ; он инициирует процесс аутентификации. Поставщик удостоверений (IdP) — авторитетный источник данных об идентичности, который аутентифицирует субъекта и выпускает утверждения; примеры: Microsoft Azure AD, Okta, Ping Identity и ADFS. Поставщик услуг (SP) принимает утверждение и предоставляет доступ на его основании; примеры: Salesforce, Google Workspace, AWS и любое приложение с поддержкой SAML. SP и IdP заранее устанавливают доверие, обмениваясь метаданными, содержащими URL конечных точек и сертификаты подписи друг друга.
OAuth 2.0: платформа авторизации
OAuth 2.0 — это платформа авторизации (а не протокол аутентификации), позволяющая стороннему приложению получать доступ к ресурсам от имени пользователя без раскрытия его учётных данных. Классический пример: «Разрешить этому приложению для редактирования фотографий доступ к Вашим Google Photos». OAuth 2.0 вводит четыре роли: владельца ресурса (пользователь), Client (стороннее приложение), сервер авторизации (выпускает маркеры) и сервер ресурсов (хранит защищённый ресурс). Пользователь авторизует Client, который получает маркер доступа и предъявляет его серверу ресурсов, не раскрывая настоящий пароль пользователя.
Поток кода авторизации OAuth 2.0
Поток кода авторизации — наиболее безопасный поток OAuth 2.0 для веб-приложений. Он выглядит так: (1) Client перенаправляет пользователя на сервер авторизации с запрошенными областями действия; (2) пользователь проходит аутентификацию и даёт согласие на сервере авторизации; (3) сервер авторизации перенаправляет пользователя обратно с короткоживущим кодом авторизации; (4) Client обменивает код на маркер доступа (и, при необходимости, маркер обновления) посредством серверного вызова с учётными данными Client; (5) Client использует маркер доступа для вызова сервера ресурсов. Обмен кодом выполняется на стороне сервера, поэтому маркер доступа не попадает в историю браузера или журналы.
# OAuth 2.0 Authorization Code Flow (step 3-4)
# Step 3: User is redirected back to client with auth code
# GET https://app.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
# Step 4: Client exchanges code for access token (server-to-server)
curl -X POST https://auth.example.com/oauth2/token \
-d 'grant_type=authorization_code' \
-d 'code=SplxlOBeZQQYbYS6WxSbIA' \
-d 'redirect_uri=https://app.example.com/callback' \
-d 'client_id=client_abc' \
-d 'client_secret=secret_xyz'
# Response: {'access_token': 'MTQ0Nj...', 'token_type': 'Bearer', 'expires_in': 3600}OpenID Connect: добавление аутентификации в OAuth
OpenID Connect (OIDC) — это уровень аутентификации, построенный поверх OAuth 2.0. OAuth предоставляет только авторизацию (маркеры доступа подтверждают, что может делать Client); OIDC добавляет аутентификацию (показывающий личность пользователя маркер ID). OIDC добавляет область действия openid в поток OAuth и возвращает подписанный JWT (веб-токен JSON) — маркер ID вместе с маркером доступа. Маркер ID содержит утверждения (имя, адрес электронной почты, sub [идентификатор субъекта]), идентифицирующие пользователя. Теперь OIDC является основным протоколом SSO для пользовательских сервисов — кнопки «Войти через Google/Apple/Microsoft» используют именно OIDC.
# OIDC ID Token is a JWT with three base64url-encoded parts:
# header.payload.signature
# Decoded payload example:
# {
# 'iss': 'https://accounts.google.com',
# 'sub': '110169484474386276334',
# 'aud': 'client_id_abc123',
# 'exp': 1750000000,
# 'iat': 1749996400,
# 'email': 'alice@gmail.com',
# 'name': 'Alice Smith',
# 'email_verified': true
# }
# The signature is verified with the IdP's public key (from JWKS endpoint)JWT: маркеры в современной аутентификации
Веб-токены JSON (JWT) — это компактный формат, безопасный для использования в URL, предназначенный для передачи утверждений между сторонами. JWT состоит из трёх частей, закодированных в формате base64url и разделённых точками: Header (алгоритм и тип маркера), Payload (утверждения: iss, sub, aud, exp, iat и пользовательские утверждения) и Signature (криптографическая подпись, подтверждающая целостность маркера). JWT являются самодостаточными — сервер ресурсов может проверить их без обращения к серверу авторизации, что повышает производительность и позволяет создавать архитектуры без состояния. Критически важное требование безопасности: всегда проверяйте подпись JWT, а также утверждения exp (срок действия) и aud (аудитория).
# Decode a JWT (header and payload are just base64 encoded)
import base64, json
jwt = 'eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiZXhwIjoxNzUwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c'
parts = jwt.split('.')
print('Header:', json.loads(base64.b64decode(parts[0] + '==')))
print('Payload:', json.loads(base64.b64decode(parts[1] + '==')))
# Signature (parts[2]) must be verified with IdP public key!SAML и OAuth и OIDC: когда что использовать
Для экзамена Security+ крайне важно понимать, когда применяется каждый стандарт. SAML 2.0: корпоративный SSO для веб-приложений, потоки на основе браузера, утверждения XML. Это устаревший, но широко распространённый в организациях стандарт. OAuth 2.0: авторизация API — предоставление сторонним приложениям ограниченного доступа к ресурсам. Он не выполняет непосредственную аутентификацию пользователей. OIDC: аутентификация пользователей и современных корпоративных систем (SSO), построенная на OAuth 2.0. Возвращает маркеры ID JWT, идентифицирующие пользователя. На практике корпоративные среды часто используют SAML для SSO приложений, а OIDC — для аутентификации API и мобильных приложений. Современные облачные среды предпочитают OIDC вместо SAML благодаря формату JSON/JWT и лучшей поддержке мобильных устройств.
Векторы атак на федерацию
Федеративные системы идентификации подвержены особым векторам атак. Атаки с повторным воспроизведением утверждения: злоумышленник перехватывает утверждение SAML и повторно отправляет его, чтобы получить доступ. Мера защиты — короткий срок действия утверждения и идентификаторы утверждений, предназначенные для однократного использования. Обёртывание XML-подписи (XSW): в SAML злоумышленники иногда могут изменить подписанный XML, чтобы подменить утверждения, сохранив действительной подпись исходного содержимого. Подмена алгоритма JWT: если сервер принимает алгоритмы RS256 (асимметричный) и HS256 (симметричный), злоумышленник может подделать JWT, используя открытый ключ сервера как секрет HMAC для HS256. Всегда проверяйте, что алгоритм в заголовке соответствует ожидаемому алгоритму. Открытые перенаправители: URI перенаправления OAuth должны сопоставляться точно, чтобы предотвратить кражу маркеров через перенаправление на сайты, контролируемые злоумышленником.
Федерация каталогов и SCIM
Федерация удостоверений в организациях часто требует синхронизации данных об идентичности пользователей между системами. SCIM (система управления идентичностью между доменами) — это стандарт REST API для автоматизации создания и удаления учётных записей пользователей между поставщиком удостоверений и подключёнными поставщиками услуг. Когда в Azure AD (IdP) добавляется новый сотрудник, SCIM автоматически создаёт его учётные записи в Salesforce, Slack, GitHub и других приложениях, совместимых с SCIM. После увольнения сотрудника SCIM одновременно деактивирует все его учётные записи, закрывая окно возможностей для эксплуатации осиротевших учётных записей. SCIM дополняет протоколы SSO (SAML/OIDC), управляя жизненным циклом, который эти протоколы не охватывают.
Быстрая проверка
Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.
Итоги урока
В этом уроке Вы узнали, что SAML 2.0 использует утверждения XML для корпоративного SSO через браузер; OAuth 2.0 является платформой авторизации для делегирования доступа к API; OpenID Connect добавляет аутентификацию (маркеры ID JWT) поверх OAuth; а SCIM автоматизирует управление жизненным циклом идентичности в федеративных системах. На этом курс «Аутентификация и авторизация» завершён — далее мы рассмотрим основы сетевой безопасности.
Изучай Security+ Academy с ИИ-репетитором — бесплатно
Пиши и запускай код прямо в браузере, получай мгновенную помощь от ИИ-репетитора 24/7 и продолжи учиться на сайте или в приложении.
- Курсы
- 30
- Уроки
- 120
Часто задаваемые вопросы
Урок «Федеративная идентификация: SAML, OAuth и OpenID Connect» бесплатный?
Да — полный текст урока «Федеративная идентификация: SAML, OAuth и OpenID Connect» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Security+ Academy, подпишись на CoddyKit PRO. Курс Security+ Academy содержит 4 уроков всего.
Чему я научусь в уроке «Федеративная идентификация: SAML, OAuth и OpenID Connect»?
Узнайте, как SSO, утверждения SAML, сценарии OAuth 2.0 и токены OpenID Connect позволяют пользователям безопасно проходить аутентификацию один раз в разных приложениях. Ты практикуешь Security+ Academy с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Security+ Academy?
Предыдущий опыт не требуется. Security+ Academy на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.
Сколько времени занимает урок «Федеративная идентификация: SAML, OAuth и OpenID Connect»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Security+ Academy?
Да. Каждый урок Security+ Academy включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Политики паролей и многофакторная аутентификация
- Биометрия и аутентификация по токенам
- Модели авторизации: RBAC, MAC и DAC
- Федеративная идентификация: SAML, OAuth и OpenID Connect