OpenID Connect (OIDC) используется для интеграции Qlik Cloud с поставщиками удостоверений. OIDC — это тонкий слой удостоверения поверх протокола OAuth 2.0. OAuth 2.0 — стандартный протокол для авторизации, а OIDC — стандартный протокол для проверки подлинности пользователей. Вместе эти два протокола обеспечивают безопасный доступ к нескольким приложениям и веб-сайтам через единый вход (SSO), при этом не нужно несколько раз входить в систему.
OAuth 2.0 предназначен только для авторизации. Можно открыть доступ к данным и функциям из одного приложения в другом, предоставив ключ запрашивающему клиенту. Используя ключ, не нужно раскрывать свои учетные данные. Вместо этого вы будете повторно использовать свои учетные данные в приложении, в котором вы уже зарегистрированы как пользователь, например, в провайдере электронной почты. Ключ гарантирует, что вы поделитесь только той информацией, которой согласны поделиться. Также можно отозвать ключ при необходимости.
Ключ полезен, но не дает информации о вас как о пользователе. OIDC добавляет функции, относящиеся ко входу в систему, и информацию о профиле лица, которое вошло в систему при помощи токенов идентификации. OIDC позволяет различным клиентам (веб-клиентам, мобильным клиентам, JavaScript и другим) проверять удостоверение пользователя на основе проверки подлинности, выполненной сервером авторизации. Клиенты также могут запрашивать основную информацию о пользователе из профиля.
Для знакомства с OAuth и OpenID Connect см. следующее видео: Иллюстрированное руководство по OAuth и OpenID Connect.
Токены идентификации
OpenID Connect использует токены идентификации, которые упрощают интеграцию и поддерживают большое разнообразие приложений.
Токен идентификации — это особым образом отформатированная строка символов, известная как Веб-токен JSON или JWT. JWT универсальны и поддерживают широкий спектр алгоритмов подписи и шифрования. Клиенты могут извлекать информацию, встроенную в JWT, такую как идентификатор, имя, время входа в систему, истечение срока действия токена идентификации и наличие попыток незаконно изменить JWT. Части данных в токене идентификации называют утверждениями.
Как упоминалось ранее, клиенты используют потоки OAuth 2.0 для получения токенов идентификации, которые работают как с веб-приложениями, так и с собственными мобильными приложениями.
Токены доступа
В дополнение к токенам идентификации существуют также токены доступа: учетные данные, которые могут использоваться приложением для доступа к API-интерфейсу. Токен доступа может быть токеном JWT или токеном, не являющимся JWT. Токен используется для того, чтобы сообщить API-интерфейсу, что носителю этого токена был предоставлен доступ к API-интерфейсу.
Утверждения
Токены JWT содержат утверждения, которые являются инструкциями (такими как имя или адрес электронной почты) об элементе (обычно это пользователь) и содержат дополнительные метаданные.
Спецификация OIDC определяет набор стандартных утверждений. Он включает имя, электронную почту, пол, дату рождения и т. д. Если необходимо собрать информацию о пользователе, которая не включена в стандартное утверждение, можно создать пользовательские утверждения и добавить их к токенам.
Спецификация OpenID Connect
Спецификация OpenID Connect 1.0 состоит из следующих документов. Qlik поддерживает эту спецификацию, но не все ее пользовательские реализации поставщиков. Qlik может для своих клиентов добавить удобную конфигурацию для популярных продуктов и платформ управления удостоверениями.
- Ядро: определяет базовую функциональность OpenID Connect: проверка подлинности, созданная поверх OAuth 2.0, и использование утверждений для передачи информации о пользователе
- Обнаружение (дополнительно): определяет, как клиенты динамически обнаруживают информацию о поставщиках OpenID
- Динамическая регистрация (дополнительно): определяет, как клиенты динамически регистрируются у поставщиков OpenID
- Несколько типов ответа OAuth 2.0: определяет несколько специфических новых типов ответа OAuth 2.0
- Режим ответа Post формы OAuth 2.0 (дополнительно): определяет, как возвратить параметры ответа авторизации OAuth 2.0 (включая параметры ответа на проверку подлинности OpenID Connect), используя значения HTML-формы, которые автоматически отправляются агентом пользователя с помощью HTTP POST
- Управление сеансами (дополнительно): определяет, как управлять сеансами OpenID Connect, включая функции основанного на postMessage выхода из системы и инициируемого проверяющей стороной (RP) выхода из системы
- Выход переднего канала (дополнительно): определяет механизм выхода переднего канала, который не использует iframe поставщика OpenID (OP) на страницах проверяющей стороны (RP)
- Выход обратного канала (дополнительно): определяет механизм выхода из системы, который использует прямую коммуникацию обратного канала информации между поставщиком OpenID (OP) и проверяющими сторонами (RP), выходящим из системы
- Федерация OpenID Connect (дополнительно): определяет, как наборы OP и RP могут установить доверительные отношения путем использования оператора федерации
Для получения документов перейдите на сайт Добро пожаловать в OpenID Connect.