Технология единого входа: как работает SSO24.11.2023 20:00

ce263dc87df442a49b5b1f9668a107db.jpg

Привет, Хабр!

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

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

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

В начале 2000-х было активное развитие технологий SSO. Организации начали внедрять SSO для упрощения доступа к корпоративным приложениям и ресурсам. Это также был период появления стандартов, таких как Kerberos, который лег в основу многих ранних реализаций SSO.

С развитием облачных технологий и мобильных устройств SSO начало получать ещё большее распространение. Возникли такие стандарты, как OAuth и OpenID, которые позволили SSO выйти за пределы корпоративных сетей и обеспечить интеграцию с обширным спектром внешних онлайн-сервисов и приложений.

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

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

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

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

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

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

Существует несколько типов токенов, используемых в SSO:

SAML токены

SAML (Security Assertion Markup Language) токены являются стандартом, используемым для обмена аутентификационной и авторизационной информацией между Identity Provider (IdP) и Service Provider (SP). SAML токены основаны на XML и содержат утверждения (claims), которые включают информацию об идентификаторе пользователя, атрибутах, правах доступа и других данных, необходимых для аутентификации и авторизации пользователя.

OAuth токены

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

Типы:

  • Access Tokens: Используются для доступа к защищенным ресурсам от имени пользователя. Они имеют ограниченный срок действия и определенный набор прав доступа.

  • Refresh Tokens: Предназначены для получения новых Access Tokens после истечения их срока действия. Эти токены имеют более длительный срок жизни и используются для поддержания активности сессии без необходимости повторной аутентификации пользователя.

OpenID connect ID токены

ID токены в OpenID Connect представляют собой форму JWT (JSON Web Tokens), используемые для подтверждения идентификации пользователя у IdP. ID токены содержат информацию о пользователе (как правило, в формате JSON), включая идентификатор пользователя, время выпуска токена, время истечения токена и другие данные.

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

Как происходит валидация токена в SSO:

Всё начинается с момента, когда сервис-провайдер (SP) получает токен от пользователя (обычно после того, как пользователь успешно аутентифицировался у провайдера идентификации, или IdP).

Один из первых шагов — проверка цифровой подписи токена. Цифровая подпись гарантирует, что токен не был изменен после того, как он был выдан IdP. Для проверки подписи SP использует общедоступный ключ IdP. Если подпись не совпадает, токен считается недействительным.

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

SP проверяет, что токен был выдан ожидаемым IdP (издателем) и что он предназначен для данного SP (аудитории). Это предотвращает ситуации, когда токен, предназначенный для одного приложения, используется для доступа к другому.

Токен содержит утверждения (claims) о пользователе, такие как его идентификатор, роли, права доступа и прочее. SP анализирует эти утверждения, чтобы определить, имеет ли пользователь необходимые права для доступа к ресурсам.

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

В некоторых случаях SP может запросить у IdP новый токен (например, обновленный или с другими утверждениями) для продолжения сессии.

Управление сессией

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

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

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

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

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

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

Протоколы и стандарты

SSO работает на основе различных протоколов, включая OAuth, OpenID Connect и SAML. Эти протоколы определяют, как токены передаются между клиентом и сервером. SAML, например, широко используется в корпоративных SSO решениях, в то время как OAuth и OpenID Connect чаще применяются для веб-приложений:

1. SAML (Security Assertion Markup Language)

SAML — это стандарт, основанный на XML, для обмена аутентификационными и авторизационными данными между двумя сторонами — провайдером идентификации (IdP) и поставщиком услуг (SP).

  • Как работает:

    • В SSO на базе SAML, когда пользователь пытается получить доступ к приложению, SP отправляет запрос аутентификации в IdP.

    • IdP аутентифицирует пользователя и отправляет обратно SP утверждение SAML, которое содержит подтверждение аутентификации и необходимые атрибуты пользователя.

    • SP проверяет это утверждение и, если все в порядке, предоставляет пользователю доступ.

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

2. OAuth (Open Authorization)

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

  • Как работает:

    • В системе, основанной на OAuth, пользователь предоставляет приложению «токен доступа», который ограничивает доступ приложения к определенным ресурсам и/или действиям от имени пользователя.

    • Приложение использует этот токен для запроса ресурсов от ресурсного сервера.

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

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

3. OpenID Connect

OpenID Connect — это слой идентификации, построенный поверх OAuth 2.0. Он позволяет клиентам проверять идентичность конечного пользователя на основе аутентификации, выполненной IdP.

  • Как работает:

    • OpenID Connect расширяет OAuth, добавляя возможность аутентификации пользователя и получения базовой информации о его профиле.

    • После успешной аутентификации пользователя, IdP предоставляет приложению ID токен (обычно в формате JWT — JSON Web Token), который содержит информацию о пользователе.

    • Приложение затем может использовать этот токен для запроса дополнительных данных о пользователе из IdP.

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

Identity Provider (IdP)

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

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

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

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

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

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

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

В случае федеративного SSO, IdP может предоставлять услуги аутентификации для множества различных SPs (про SP чуть ниже), что позволяет пользователям использовать единые учетные данные для доступа к разным сервисам.

Service Provider (SP)

Service Provider (SP) позволяет пользователям получать доступ к различным приложениям и сервисам, используя учетные данные, аутентифицированные через Identity Provider (IdP). В рамках системы SSO, SP взаимодействует с IdP для управления доступом и проверки удостоверений пользователя.

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

После аутентификации пользователя IdP отправляет SP аутентификационный токен (например, SAML Assertion, OAuth Token, JWT). SP затем должен валидировать этот токен, чтобы убедиться в подлинности и актуальности информации.

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

SP должен поддерживать протоколы и стандарты, используемые IdP, для обеспечения совместимости и безопасного обмена данными.

Безопасность

Основная угроза заключается в потенциальном перехвате или подделке токенов аутентификации. Для противодействия этим угрозам в SSO используется ряд технических механизмов и методов

Шифрование токенов

  1. Шифрование на транспортном уровне:

    • Использование протоколов, таких как TLS, для обеспечения безопасной передачи токенов между клиентом и сервером.

    • Это предотвращает «man-in-the-middle» атаки, при которых злоумышленник может перехватить данные, передаваемые по сети.

  2. Шифрование содержимого токена:

    • Для защиты конфиденциальной информации внутри токена используются методы шифрования, например, AES (Advanced Encryption Standard). Это важно для токенов, содержащих чувствительные данные, к примеру утверждения о правах доступа пользователя.

Цифровые подписи

  1. Использование подписей:

    • Чтобы гарантировать целостность и подлинность токена, применяются цифровые подписи. Например, в JWT (JSON Web Tokens) используется механизм подписи, такой как RSASSA-PKCS1-v1_5 с использованием SHA-256 (RS256).

  2. Ключи для подписей:

    • Для создания и проверки подписей используются пары ключей (публичный и приватный). IdP подписывает токен своим приватным ключом, а SP использует публичный ключ IdP для проверки подписи.

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

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

User Agent

User Agent в контексте систем SSO обычно представляет собой веб-браузер пользователя, который выполняет ряд функций для обеспечения процесса аутентификации и управления доступом.

User Agent служит основным интерфейсом для взаимодействия пользователя с системой SSO. Через браузер пользователь входит в систему, вводит учетные данные и управляет своими сессиями. User Agent перенаправляет запросы между пользователем и различными компонентами системы SSO, включая IdP и SP. Это включает инициализацию процесса аутентификации, передачу токенов аутентификации и других соответствующих данных.

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

User Agent использует куки для управления сессиями пользователя, сохраняя информацию о текущем статусе аутентификации. Это позволяет пользователю переходить между различными SP без повторного ввода учетных данных.

Браузеры имеют встроенные механизмы безопасности, такие как обеспечение безопасных соединений через HTTPS, что помогает защищать данные аутентификации при их передаче. User Agent предоставляет интерактивный интерфейс, через который пользователи получают уведомления, например, о необходимости повторной аутентификации или о истечении сессии.

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

К примеру на практике User Agent может выглядеть таким образом:

Сотрудники используют стандартные веб-браузеры (например, Chrome, Firefox, Safari) как User Agent для доступа к корпоративным ресурсам. При первом входе в любое из корпоративных приложений через браузер, сотрудник перенаправляется на централизованную страницу аутентификации (предоставляемую IdP).

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

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

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

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

SSO в различных средах

SSO в корпоративной среде

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

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

SSO позволяет более эффективно контролировать доступ к корпоративным ресурсам, внедряя политики безопасности и отслеживая активности пользователей.

SSO в облачных сервисах

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

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

SSO в мобильных и веб-приложениях

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

В мобильной среде SSO особенно ценно, поскольку позволяет пользователям доступать к сервисам с минимальными усилиями.

Международные стандарты и нормативные требования

  1. ISO/IEC 27001:

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

    ISO/IEC 27001

  2. OpenID Connect:

    • Это открытый стандарт идентификации, основанный на OAuth 2.0. Он предоставляет дополнительный слой идентификации для SSO и требует строгого соответствия протоколам безопасности при обмене данными аутентификации.

    OpenID Connect

  3. SAML (Security Assertion Markup Language):

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

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

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

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

Ознакомиться с GDPR можно здесь.

Реализация SSO на примере…моих любимых ботов в телеге.

Интеграция с SSO

Определите, какие функции вам нужны от SSO провайдера, такие как поддержка протоколов (например, SAML, OpenID Connect), наличие API, удобство интеграции, уровень безопасности и пр.

Рассмотрите различные SSO провайдеры, такие как Auth0, Okta или Google:

  1. Auth0: Популярный вариант с гибкими возможностями настройки и большим количеством документации.

  2. Okta: Ориентирован на корпоративные решения, предлагает широкий спектр функций безопасности и управления.

  3. Google: Простой в использовании и хорошо интегрируется с другими сервисами Google.

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

После регистрации приложения, вы получите Client ID и Client Secret. Эти данные понадобятся для настройки OAuth 2.0.

Реализация аутентификации в боте

Сначала нужно зарегистрировать вашего бота в Okta как новое приложение и получить необходимые учетные данные, включая Client ID и Client Secret, а также настроить URL перенаправления (callback URL). Предполагая, что эти шаги уже выполнены, давайте реализуем функцию генерации URL в боте:

  1. Определение команды /login: 

import telebot
from urllib.parse import urlencode

# Константы, связанные с вашим приложением Okta
OKTA_DOMAIN = 'https://your-okta-domain.okta.com'
CLIENT_ID = 'your-client-id'
CLIENT_SECRET = 'your-client-secret'
REDIRECT_URI = 'https://your-redirect-uri/callback'
AUTHORIZATION_ENDPOINT = OKTA_DOMAIN + '/oauth2/default/v1/authorize'

# Создайте экземпляр бота
bot = telebot.TeleBot('YOUR_TELEGRAM_BOT_TOKEN')

def generate_auth_url():
    # Параметры для URL аутентификации
    params = {
        'client_id': CLIENT_ID,
        'response_type': 'code',
        'scope': 'openid profile email',
        'redirect_uri': REDIRECT_URI,
        'state': 'some-random-state',
        'nonce': 'another-random-value'
    }
    # Генерация URL
    url = AUTHORIZATION_ENDPOINT + '?' + urlencode(params)
    return url

@bot.message_handler(commands=['login'])
def login(message):
    auth_url = generate_auth_url()
    bot.send_message(message.chat.id, "Пожалуйста, войдите используя этот URL: " + auth_url)

# Запуск бота
bot.polling()

Вам нужно заменить YOUR_TELEGRAM_BOT_TOKEN, your-okta-domain, your-client-id, your-client-secret и your-redirect-uri на реальные данные вашего Telegram бота и приложения Okta.

  • Используется библиотека telebot для создания бота и обработки команды /login.

  • generate_auth_url формирует URL для аутентификации, используя данные вашего приложения в Okta.

  • При вызове команды /login, пользователю отправляется сгенерированный URL.

  1. Обработка Callback URL:

Для обработки Callback URL после аутентификации пользователя через Okta в боте, потребуется веб-сервер, который будет слушать запросы на указанный URL перенаправления (callback URL). Этот сервер обрабатывает код аутентификации, полученный от Okta, и обменивает его на токен доступа. Для этого можно использовать, например, Flask — легковесный веб-фреймворк для Python.

Установите Flask: 

pip install Flask

Код для обработки Callback URL: 

from flask import Flask, request, redirect
import requests
import telebot

# Параметры вашего приложения в Okta и телеграм бота
CLIENT_ID = 'your-client-id'
CLIENT_SECRET = 'your-client-secret'
REDIRECT_URI = 'https://your-redirect-uri/callback'
TOKEN_ENDPOINT = 'https://your-okta-domain.okta.com/oauth2/default/v1/token'

app = Flask(__name__)

# Создайте экземпляр бота
bot = telebot.TeleBot('YOUR_TELEGRAM_BOT_TOKEN')

@app.route('/callback')
def callback():
    # Получение кода аутентификации из запроса
    auth_code = request.args.get('code')
    if auth_code:
        # Обмен кода на токен доступа
        token_response = requests.post(TOKEN_ENDPOINT, data={
            'grant_type': 'authorization_code',
            'code': auth_code,
            'redirect_uri': REDIRECT_URI,
            'client_id': CLIENT_ID,
            'client_secret': CLIENT_SECRET
        }).json()

        access_token = token_response.get('access_token')
        if access_token:
            # Сохраните токен доступа для дальнейшего использования
            # (например, в базе данных)
            return 'Аутентификация успешна!'
        else:
            return 'Ошибка при обмене кода на токен доступа.'
    else:
        return 'Ошибка: код аутентификации не предоставлен.'

if __name__ == '__main__':
    app.run()

  • Веб-сервер Flask слушает запросы на /callback.

  • После перенаправления пользователя на этот URL сервер получает код аутентификации.

  • Сервер обменивает код аутентификации на токен доступа, отправляя POST-запрос на TOKEN_ENDPOINT Okta.

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

На этом все!

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

Спасибо за ваше внимание!

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

© Habrahabr.ru