Некоторое время назад я получил довольно непростую задачу написать техническое задание для нашей службы поддержки на тему OpenID Connect (OIDC).
Тут же я понял, что хоть я и знаком с OAuth и SAML, я не знал практически ничего об OpenID Connect (кроме того, что благодаря этому Pokemon Go получает сведения о моем профиле сразу после авторизации в Google+).
К счастью, мои коллеги подробно посвятили меня во все детали и снабдили необходимыми ресурсами для ознакомления. Хотя, честно говоря, ни одно из объяснений не показалось мне достаточно хорошим и качественным. Поэтому представляю моё видение данного процесса.
Основы OIDC
Если просто, то OIDC — это безопасный механизм, позволяющий приложению связаться со службой идентификации, чтобы получить необходимые данные о пользователе и вернуть их обратно в приложение, обеспечив полную защиту данных.
По своей сути, OpenID Connect начинал свой путь как механизм авторизации OAuth "любительского уровня" или, если говорить более высокопарно, "механизм, предоставляющей пользователю возможность создать единую учетную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов".
Именно поэтому, в нем есть много схожих деталей с OAuth таких, как: client_id, client_secret и redirect_uri, которые хранятся в системе управления доступами. Все они предназначены для того, чтобы обеспечить передачу данных от конкретного человека конкретному приложению. Проще говоря, OIDC предотвращает кражу client_id и отправляет данный запрос обратно на www.evil_hacker.com.
Каждый, кто хоть раз участвовал в викторине "Кто ты из…?" на Facebook, уже имел шанс ознакомиться с процессами OAuth в действии: сначала нужно авторизоваться в системе управления доступами (в данном случае — Facebook), а затем дать права на использование персональных данных с вашей страницы.
Важно отметить, что такие права называются scopes — области видимости. Для OIDC существует особая область видимости openid, которую необходимо использовать в качестве первого обращения к системе управления доступами.
Сразу после того, как мы разобрались со scopes, возникает следующий резонный вопрос: “Как работать с OpenID?”.
Познакомимся с флоу работы с OpenID
Порядок работы с OpenID connect во многом зависит от типа клиента, который вы используете и от того, насколько хорошо он умеет хранить секреты.
Например, если вы используете приложение JavaScript, где всё и вся может просматриваться любым, кто использует инструменты-разработчики браузера, а также отсутствует бэкенд-механизм, чтобы скрыть информацию от любопытных глаз пользователей — на помощь придет Implicit Flow для OpenID Connect.
Если же вы пользуетесь более традиционными приложениями, где какая-то информация передается на фронтенд (и есть вероятность, что кто-то может ее перехватить), но в то же время используется бэкенд, чтобы передавать информацию службе управления доступами абсолютно конфиденциально, используйте Authentication Flow.
Также существует Hybrid Flow, который является сочетанием двух вышеупомянутых методов.
A. Implicit Flow
Этот флоу разработан для передачи основной информации о пользователе приложению. И на этом всё.
Хотя нет…
В спецификации OIDC обращается особое внимание, что запрашиваемая информация о пользователе должна быть упакована в JWT (JSON токен), зашифрована или подписана. Более того, информация об этих шагах (как и когда упакована/зашифрована/подписана) должна быть включена в набор данных, отправляемых обратно.
В конечном счете, требования к Implicit flow таковы: он должен использовать схему открытого / закрытого ключа для шифрования или подписи информации о пользователе, а также содержать в полной конфиденциальности client_secret.
Таким образом приложение может удостовериться в том, что данные о пользователе (именуемые claims в OIDC) поступают из надежного источника (что это не переадресация на поддельный URL от www.evil_hacker.com) и частная информация (к примеру, client_secret) полностью защищена от посторонних глаз.
В принципе, любой может "украсть" открытый ключ и идентификатор пользователя, но это не имеет абсолютно никакого значения, поскольку только система управления доступами владеет необходимой информацией (URL-адресом переадресации и секретным ключом), чтобы использовать ее по назначению.
B. Authentication Flow
Данный флоу разработан, чтобы функционировать как стандартный three-legged OAuth. В итоге обычный токен доступа OAuth секретным образом возвращается в веб-приложение через вызовы, сделанные на серверной части.
В таком флоу вместо передачи данных о пользователе, служба управления доступами отправляет специальный одноразовый пароль, который можно обменять на токен доступа OAuth через бэкенд сервис. Такой обмен должен включать client_id и client_secret в дополнение к коду, также, как и в стандартном флоу OAuth.
Затем токен доступа OAuth должен быть использован веб-сервисом для подтверждения подлинности, а также для запроса разного рода информации о пользователе (это определяется запрошенными типами scopes и claims).
Сейчас, в мире, где существуют разнообразные службы управления доступами, такие claims обычно предварительно утверждаются администратором, отвечающим за настройку приложения, но на любительском уровне (где непосредственно конечный пользователь подтверждает доступ к приложению) они выступают в виде запросов на разрешение (scopes) во время изначального application flow.
OIDC определяет целый ряд claims, и некоторые из них имеют довольно узкое определение (например, только email адрес пользователя), в то время, как другие являются довольно обширными и могут возвращать любую запрошенную информацию системе управления доступами (такую, как, например, информация о профиле пользователя).
В дополнение, хочется отметить, что cистемы OIDC также предоставляют refresh-токен (если веб-сервису необходим более длительный доступ к информации о пользователе), так же, как и персонализированные claims.
C. Hybrid Flow
Данный флоу сочетает в себе характеристики двух вышеупомянутых типов с одним небольшим преимуществом: такой флоу позволяет передавать токен доступа напрямую клиенту.
Общепринятым считается, что front channel токен не настолько безопасен, как, например, back channel токен, поэтому иногда их срок службы короче и может быть увеличен за счет back-channel вызовов.
Общеизвестный endpoint
Вы, вероятно, уже заметили, что клиенту нужно владеть немалым объемом информации, чтобы правильно выполнять различные рукопожатия OIDC и обмениваться информацией. Плюс ко всему, немаловажным является вопрос куда он должен обратиться чтобы получить ключи доступа, используемые для подписи или шифрования этой информации.
Чтобы упростить этот процесс, провайдеры OIDC могут поддерживать общеизвестный endpoint. В таком случае OIDC самостоятельно определяет набор опций, которые могут быть переданы клиенту для настройки вручную. И хотя часть этой информации вряд ли изменится, другие части специально предназначены для периодического обновления.
Например, если вы зайдете на https://accounts.google.com/.well-known/openid-configuration вы обнаружите запись "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs"
jwks_uri — это URL, к которому клиент может получить доступ для получения информации о любых ключах JWK, используемых Google, в формате, установленном спецификацией OIDC.
Одно из значений, возвращаемых для каждого ключа, — это ключевой id (kid), который можно использовать для того, чтобы определить, изменился ли криптографический ключ.
Проще говоря, проверив этот показатель/значение, клиент может определить, изменился ли открытый ключ у системы управления доступом с момента его последнего использования, и автоматически обновиться, чтобы использовать эту информацию.
Посмотрите, к примеру, на SAML. По этой логике здесь работает автоматическая ротация ключей (automatic key rotation).
Заключение
В этом обзоре я постарался простым языком рассказать про азы и основные моменты каждого из флоу. Вместе с тем, гораздо более умные ребята, чем я, уже давно выпустили официальные спецификации со всеми подробностями. Я настоятельно рекомендую вам ознакомиться с ними перед началом работы.
Также сообщество разработчиков OpenID проделало огромную работу и разработало множество классных инструментов, которые помогут вам сделать первые шаги и начать экспериментировать.
И наконец, OIDC — это стандарт. На его основе уже разработано большое количество OIDC-клиентов. Возможно, в вашем случае даже не потребуется создавать свой. Главное, теперь, когда у вас есть понимание основных типов флоу и их применимости — убедитесь, что вы выбрали подходящий тип для вашего конкретного случая!
И если вы в поисках провайдера OpenID Connect — ознакомьтесь с нашим.