В статье «Развитие безопасного «облака»» (опубликованной в Windows IT Pro/RE № 9 за 2013 год), речь шла о том, как важно, чтобы предприятия поддерживали открытые стандарты учетных данных в Интернете и требовали того же от своих поставщиков услуг. Пора познакомить вас с относительно новыми и очень важными инфраструктурами учетных данных OAuth 2.0 и OpenID Connect, составляющими своего рода «Kerberos для «облака»». Как и в случае с Kerberos, даже если вы сами не разрабатываете код, использующий этот протокол, вы должны, по крайней мере, знать, как он работает, ведь пользователи все чаще задействуют мобильные и «облачные» приложения.
Всем хорошо знакома проблема паролей. Нам трудно держать в памяти огромное количество своих имен и паролей, поэтому мы делаем их простыми, чтобы облегчить запоминание. Простые пароли мы используем повторно на многих сайтах, чтобы избежать путаницы. Многие ли придерживаются правил «информационной ги-гиены» для защиты своих личных данных? Ситуация усугубляется и порочной практикой входа по паролю, когда мы безропотно вводим имя и пароль всякий раз, когда видим запрос на ввод учетных данных. Такая доверчивость облегчает вредоносным программам задачу получения доступа к персональным данным. В мае на конференции Glue эксперт по разработке из Google Тим Брэй упал на колени, изображая от имени всех разработчиков мольбу о том, чтобы от них не требовали создания очередного имени и пароля для каждого нового сайта.
С мобильными устройствами ситуация еще сложнее. Трудность ввода учетных данных усугубляется при использовании устройств меньшего размера; на маленькой клавиатуре пароль вводить сложнее (а пожилому человеку для этого нередко приходится надевать очки). Это значительно затрудняет применение надежных паролей. Однажды введенные, пароли часто хранятся без надлежащей защиты в памяти устройства, которое может быть потеряно. Многие ли из нас используют PIN-коды или другие виды блокировки для своих мобильных устройств? По данным опроса, проведенного в 2011 г. компанией Confident Technologies, блокировку применяют менее половины пользователей (http://confidenttechnologies.com/news_events/survey-shows-smartphone-users-choose-convenience-over-security).
OAuth 2.0
К счастью, существует OAuth 2.0 – технология, способная помочь в решении проблемы паролей, особенно для мобильных приложений. В техническом отношении предложенный IETF стандарт OAuth 2.0 – «инфраструктура авторизации», но мне больше нравится определение «предназначенный для авторизации» гибкий протокол, поддерживающий аутентификацию.
В общих чертах OAuth 2.0 использует метод получения и исполь-зования токена (см. рисунок). Пользователь (например, приложение на клиентском компьютере или мобильном устройстве пользователя) желает получить доступ к ресурсу, защищенному сервером ресурсов. Для аутентификации при регистрации на сервере ресурсов клиент должен включить токен доступа в запрос связи с сервером. Токен выдается сервером авторизации. Другими словами, клиент получает токен от сервера авторизации и использует его для аутентификации при входе на сервер ресурсов и таким образом получает доступ к нужному ресурсу. Очевидно внешнее сходство потока клиентских учетных данных OAuth 2.0 с потоком учетных данных Kerberos.
Рисунок. Архитектура OAuth 2.0 |
Сегодня можно встретить ряд примеров OAuth 2.0 в работе. Получая доступ к веб-приложению (например, Twitter, Tripit) с использованием своей учетной записи от поставщика учетных данных (например, Google), проследите внимательно за процессом, и вы увидите URL-адрес, который содержит oauth. Может даже на короткое время появиться логотип OAuth. Брайан Кэмпбелл в своей презентации (http://www.slideshare.net/briandavidcampbell/is-that-a-token-in-your-phone-in-your-pocket-or-are-you-just-glad-to-see-me-oauth-20-and-mobile-devices) объясняет, как OAuth 2.0 работает с мобильными клиентами, а в https://www.pingidentity.com предлагается техническое описание под названием «The Essentials Of OAuth» (https://www.pingidentity.com/support-and-downloads/download.cfm/The%20Essentials%20of%20OAuth%20White%20Paper?item=17018).
Технология OAuth 2.0 – более гибкая, чем Kerberos, но она и сложнее в реализации. Рассуждения о том, что это очередной протокол авторизации, не уменьшают существующего беспорядка. Именно здесь в дело вступает OpenID Connect.
OpenID Connect
OpenID Connect – это простой слой учетных данных поверх OAuth 2.0. Это спецификация, которая организует процесс обмена данными OAuth 2.0 между поставщиками учетных данных и проверяющими сторонами без необходимости вводить многочисленные данные, необходимые для реализации OAuth. Реализация OAuth упрощается благодаря тому, что спецификация добавляет нужные детали и вставляет ряд значений по умолчанию. Кроме того, конфигурации OAuth стандартизируются между различными реализациями, что способствует функциональной совместимости поставщиков. Поскольку это облегчает жизнь разработчикам, есть надежда, что OAuth 2.0 все чаще будет использоваться для обеспечения безопасной аутентификации. Статья Памелы Дингл «OpenID Connect: New, groovy and full of promise» (https://www.pingidentity.com/blogs/pingtalk/2011/08/OpenID-Connect-New-and-Groovy.html) дает общее представление о том, как это работает, а с подробным описанием можно ознакомиться в презентации Оливера Пфаффа «OpenID Connect—An Emperor Or Just New [Clothes]?» (http://www.slideshare.net/oliverpfaff/openid-connect-an-emperor-or-just-new-cloths).
В феврале аналитическая компания Gartner выдала прогноз, со-гласно которому половина посетителей сайтов розничной торговли будет авторизоваться с использованием своих учетных данных в социальных сетях (Facebook, Google, Twitter, Microsoft и др.). Однако это может произойти только при условии использования общего простого и безопасного метода обмена учетными данными между поставщиками учетных данных и поставщиками услуг, и здесь OAuth 2.0 и OpenID Connect представляются наиболее подходящими решениями.
Если ваша повседневная работа не требует привлечения внешних учетных данных, то информацию об OAuth 2.0 и OpenID Connect можно просто «отложить про запас». Если же ваша компания ра-ботает с удостоверениями клиентов, то эти две инфраструктуры учетных данных составят часть вашего будущего. Пройдите по предложенным ссылкам и проанализируйте предлагаемую информацию достаточно скрупулезно, чтобы составить свое мнение о том, как эти технологии повлияют на вашу работу.
Путаница с открытыми стандартами
Анализируя ситуацию, я был удивлен, как много путаницы может возникать в пространстве открытых стандартов по сравнению с реализацией решения от одного поставщика. Прежде всего, суще-ствует много организаций, занимающихся разработкой стандартов, например IETF, OASIS и OpenID Foundation. У каждой организации есть разные предложения и комитет, который руководит процессом создания стандартов. Каждое предложение (или инфраструктура) проходит этапы проекта, спецификации и предлагаемого стандарта, и этот перечень может меняться от организации к организации. Не все протоколы являются стандартами, и не все стандарты – протоколами, но все стандарты ранее были спецификациями. Во многих случаях активно используются именно спецификации и инфраструктуры, даже если они не являются стандартами. Кроме того, одна инфраструктура от одного органа по стандартизации (например, OpenID Connect от OpenID Foundation) может быть создана в расчете на функционирование поверх инфраструктуры от другого органа по стандартизации (например, OAuth 2.0 от IETF). Названия тоже могут вносить путаницу, даже в пределах одной организации: например, OpenID Connect не имеет никакого отношения к OpenID.