» » OpenID Connect: авторизация внутренних приложений от самописных к стандарту

 

OpenID Connect: авторизация внутренних приложений от самописных к стандарту

Автор: admin от 17-03-2020, 22:50, посмотрело: 113

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



OpenID Connect: авторизация внутренних приложений от самописных к стандарту

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



Группа клеймов объединяется в следующее подмножество – Scope. При авторизации идет запрос доступа не к конкретным клеймам, а именно к скоупам, даже если часть клеймов из скоупа не нужна.



2) Реализовали нужные гранты



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



OpenID Connect: авторизация внутренних приложений от самописных к стандарту



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



OAuth придерживается концепции, что токены доступа, полученные после авторизации, должны быть временными и меняться желательно в среднем каждые 10 минут. Грант Authorization Code является трехшаговой проверкой через редиректы, каждые 10 минут такой шаг проворачивать, честно говоря, не самое приятное для глаз занятие. Для решения этой проблемы существует еще один грант – Refresh Token, который мы у себя также задействовали. Тут все проще. Во время проверки с другого гранта, помимо основного токена доступа выдается еще один – Refresh Token, который можно использовать только один раз и время его жизни, как правило, существенно больше. С этим Refresh Token’ом, когда закончится TTL (Time to Live) основного токена доступа, запрос нового токена доступа придет на endpoint уже другого гранта. Использованный Refresh Token сразу обнуляется. Такая проверка является двухшаговой и может быть выполнена в фоне, незаметно для пользователя.



3) Настроили форматы вывода пользовательских данных



После того, как выбранные гранты реализованы, авторизация работает, стоит упомянуть о получении данных о конечном пользователе. В OIDC есть отдельный endpoint для этого, на котором со своим текущим токеном доступа и при его актуальности можно запросить данные о пользователях. И если данные пользователя не меняются так часто, а ходить за текущими нужно по многу раз, можно прийти к такому решению, как JWT-токены. Эти токены также поддерживаются стандартом. Сам по себе JWT-токен состоит из трех частей: header (информация о токене), payload (любые нужные данные) и signature (подпись, токен подписывается сервером и в дальнейшем можно проверить источник его подписи).



В имплементации OIDC JWT-токен называется id_token. Он может быть запрошен вместе с обычным токеном доступа и все, что остается – проверить подпись. У сервера авторизации для этого существует отдельный endpoint со связкой публичных ключей в формате JWK. И говоря об этом, стоит упомянуть, что существует еще один endpoint, который на основе стандарта RFC5785 отражает текущую конфигурацию OIDC-сервера. В нем содержатся все адреса endpoint’ов (в том, числе адрес связки публичных ключей, используемых для подписи), поддерживаемые клеймы и скоупы, используемые алгоритмы шифрования, поддерживаемые гранты и т.д.





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



Итоги реализации



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

Так как OIDC — это открытый стандарт, у нас появилась возможность выбора существующего провайдера или реализации сервера. Мы пробовали Keycloak, который оказался очень удобным в конфигурировании, после настройки и смены конфигураций подключения на стороне приложений он готов к работе. На стороне приложений остается только сменить конфигурации подключения.



Говоря о существующих решениях



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



Еще один пример сертифицированной, интересной, на мой взгляд, реализации — Ory Hydra. Интересна она тем, что состоит из разных компонентов. Для интеграции вам понадобится связать свой сервис менеджмента пользователей с их сервисом авторизации и расширять по мере необходимости.



Keycloak и Ory Hydra — не единственные готовые решения. Лучше всего подбирать сертифицированную OpenID Foundation реализацию. Обычно у таких решений есть значок OpenID Certification.



OpenID Connect: авторизация внутренних приложений от самописных к стандарту




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



Что дальше



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

github.com/bitly/oauth2_proxy

github.com/ory/oathkeeper

github.com/keycloak/keycloak-gatekeeper



Дополнительные материалы



jwt.io – хороших сервис для проверки JWT-токенов

openid.net/developers/certified — список сертифицированных реализаций OIDC

Источник: Хабр / Интересные публикации

Категория: Программирование

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

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *