OAuth
OAuth | |
---|---|
![]() | |
Название | OAuth |
![]() |
OAuth — стандарт (схема) авторизации, обеспечивающий предоставление третьей стороне ограниченного доступа к защищённым ресурсам пользователя без передачи ей (третьей стороне) логина и пароля[1][2].
Работа над протоколом началась в ноябре 2006 года, а последняя версия OAuth 1.0 была утверждена 4 декабря 2007 года. Как последующее развитие в 2010 году появился протокол OAuth 2.0, последняя версия которого в качестве в RFC 6749 опубликована в октябре 2012 года.
Применение
Одной из проблем аутентификации и информационной безопасности является то, что пользователи, как правило, используют несколько различных сервисов (например, на Google, Twitter, Apple и др.), и, соответственно, несколько учётных записей со своими логинами и паролями. Таким образом пользователям требуется хранить и защищать множество логинов-паролей. Поскольку каждый из сервисов имеет собственную систему безопасности со своими уязвимостями и недостатками, то всё это наносит ущерб удобству и безопасности пользователей. Например, если пользователи для разных сервисов применяют одни и те же пароли, то после получения доступа к одной из учётных записей процедура взлома для других аккаунтов для злоумышленников значительно упрощается[3].
Для усиления защиты может быть использована аутентификация в два шага (например Google Authenticator), когда для подтверждения задействуется другой сервис пользователя (например, когда для аутентификации на веб-сайте требуется ввести код, отправляемый на мобильный телефон). При таком подходе вероятность взлома значительно уменьшается. Ключевая особенность применения OAuth заключается в том, что, если пользователь имеет хорошо защищённый аккаунт, то с его помощью и технологии OAuth он может пройти аутентификацию на других сервисах, при этом пользователю не требуется раскрывать свой основной пароль. Например, пользователь, который хочет предоставить онлайн-сервису печати фотографий доступ к фотографиям своего Facebook-аккаунта, от него не требуется сообщать сервису пароль от этого аккаунта. Вместо этого он проходит авторизацию в Facebook, который (с разрешения пользователя или администратора сервиса) уже предоставляет сервису онлайн-печати требуемый доступ к фотографиям[3].
История
OAuth 1.0
OAuth появился в ноябре 2006 года, во время разработки
В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний Google и AOL (которая в это же время представила свой собственный протокол OpenAuth). Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в
15 апреля 2009 года
OAuth 2.0
В 2010 году началась работа над новой версией протокола OAuth 2.0, для которой не предусматривалась обратная совместимость с OAuth 1.0[1]. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, и использование носителя токена в RFC 6750.
Предпосылок для создания OAuth 2.0 было несколько. В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth — упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трёх методов (называемых потоками (англ. flows)) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым. В него, помимо новых потоков, были добавлены[5][6]:
- Токен на предъявителя. Метод авторизации аналогичен существующему способу авторизации с помощью ).
- Упрощенная подпись. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
- Короткоживущие токены с долговременной авторизацией. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
- Разделение ролей. За авторизацию и за предоставление доступа к API могут отвечать разные сервера.
На данный момент OAuth 2.0 используется большим количеством сервисов, таких как Google, Instagram, Facebook, ВКонтакте и другие.
Последующее развитие
В июле 2012 года Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трёх лет работы над новым стандартом и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своём сайте[7] и позже выступил с докладом[8]. Девид Рекордон (англ. David Recordon) позже также вычеркнул своё имя из спецификаций без указания причин[9]. Дик Хардт (Dick Hardt) стал редактором стандарта OAuth2.0, и, несмотря на взгляды Эрана Хаммера, структура OAuth 2.0 была опубликована в RFC 6749 в октябре 2012 года[1].
Сравнение с другими протоколами
Преимущества
При использовании OAuth-авторизации пользователь не передаёт свой логин и пароль к защищённым ресурсам напрямую в приложение[3]. Поэтому:
- У пользователя больше оснований доверять приложению, поскольку пользователь может быть уверен, что несанкционированный доступ к его личным данным невозможен. Не владея логином и паролем пользователя, приложение сможет выполнять только те действия с данными, которые разрешил пользователь, и никакие другие[3].
- При разработке приложения не нужно заботиться об обеспечении конфиденциальности логина и пароля пользователя. Логин и пароль не передаются приложению, а следовательно, они не могут попасть в руки злоумышленников[10].
В случае авторизации без использования протокола OAuth пользователю необходимо передавать свой логин и пароль. У этого способа существуют дополнительные недостатки[3]:
- Если пользователь изменяет пароль, то приложение больше не может получить доступ к защищённым ресурсам.
- Единственный способ запретить приложению доступ к защищённым ресурсам — изменить пароль. Это одновременно запретит доступ к ресурсам и другим приложениям, которые ранее его имели.
- Сервисы, хранящие защищённые ресурсы и предоставляющие API для доступа к ним, могут использовать федеративные механизмы аутентификации (англ. Federated Authentication), такие как OpenID или SAML, что позволяет пользователям не иметь пароля к их аккаунтам. Это делает невозможным для этих пользователей использование приложений, запрашивающих доступ к защищённым ресурсам через этот API.
Отличие от OpenID
Хотя OAuth и OpenID имеют много общего, OAuth является самостоятельным протоколом, никак не связанным с OpenID[10]:
- OAuth является протоколом авторизации[10], который позволяет предоставить права на использование какого-то ресурса (например, API какого-либо сервиса). Наличие прав определяется токеном (уникальным идентификатором), который может быть одним и тем же для разных пользователей, или же у одного пользователя в разное время могут быть разные токены. Предоставление прав происходит в обмен на предоставление токена. В общем случае нельзя определить, кому принадлежит токен и кто в настоящий момент пользуется правами.
- OpenID является средством аутентификации[10]: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдаёт. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.
Описание протоколов OAuth
Основные понятия, используемые в протоколах, и примеры их использования.
Клиент, сервер и владелец ресурса
OAuth 1.0 определяет три роли: клиент, сервер и владелец ресурса. Эти три роли присутствуют в любой операции OAuth, в некоторых случаях клиент также является владельцем ресурса. Оригинальная версия спецификации использует различный набор терминов для этих ролей: потребитель (клиент), услуга (сервер) и пользователь (владелец ресурса)[11]. В протоколе OAuth 2.0 произошло разделение ролей сервера: отдельно выделяется сервер авторизации и сервер, хранящий защищённые ресурсы[6].
Методы создания подписей
OAuth поддерживает 3 метода создания подписей, используемых для подписывания и проверки запросов:
Метка времени и Nonce
Чтобы предотвратить угрозу повторного использования запросов в OAuth применяются
Однако хранение всех полученных nonce может быть существенно затратным для сервера. Для предотвращения чрезмерных затрат на хранение в OAuth в каждый запрос добавляется метка времени, которая позволяет серверу хранить nonce только в течение заданного ограниченного времени. При получении запроса с меткой с более ранним, чем допустимо, временем сервер отвергает его[12].
Полномочия и токены
В OAuth 1.0 и OAuth 2.0 используются три вида полномочий: учётные данные клиента (англ. consumer key and secret или англ. client credentials), временные учётные данные (англ. request token and secret или англ. temporary credentials) и токены (англ. access token and secret или англ. token credentials)[13][3].
Учётные данные клиента используются для проверки подлинности клиента. Сервер может предоставлять клиентам специальные услуги, такие как регулирование свободного доступа или предоставление владельцу ресурса более подробной информации о клиентах, пытающихся получить доступ к защищённым ресурсам. В некоторых случаях учётные данные клиента ненадёжны и могут быть использованы только в информационных целях, например, в настольных приложениях.
Токен используется вместо имени и пароля владельца ресурса. Владелец ресурса не раскрывает свои учётные данные клиенту, а разрешает серверу выдавать клиенту токен — специальный класс учётных данных, предоставляющий клиенту некоторые ограниченные возможности. Клиент использует токен для доступа к защищённому ресурсу, не зная при этом пароля владельца ресурсов. Токен состоит из цифровой подписи, обычно (но не всегда) случайного набора букв и цифр, который является уникальным и криптографически стойким, и из ключа для защиты токена от использования посторонними лицами. Токен ограничен по полномочиям и продолжительности и может быть отозван в любой момент владельцем ресурса, при этом не затрагивает токенов, выданных другим клиентам[13].
Процесс OAuth авторизации также использует набор вре́менных учётных данных, которые задействуются на стадии запроса авторизации. В целях удовлетворения различного рода клиентов (веб-интерфейсных, настольных, мобильных и т. д.), временные полномочия предлагают дополнительную гибкость и безопасность[13].
OAuth 1.0
![](http://upload.wikimedia.org/wikipedia/commons/thumb/0/0f/OAuth.png/220px-OAuth.png)
Поясним работу протокола OAuth 1.0 на примере[13]. Допустим, что пользователь (владелец ресурсов) хочет распечатать свои фотографии (ресурсы), загруженные на сайт «photos.example.net» (сервер), при помощи сервиса печати «printer.example.net» (клиент).
- Клиент посредством протокола цифровой подписии саму подпись.
- Сервер подтверждает запрос и отвечает клиенту токеном запроса (англ. Request Token) и частью разделённого секрета.
- Клиент передаёт токен владельцу ресурсов (пользователю) и перенаправляет его на сервер для прохождения аутентификации.
- Сервер, получив от пользователя токен, запрашивает у него его логин и пароль, и в случае успешной аутентификации просит пользователя подтвердить доступ клиента к ресурсам (происходит авторизация), после чего пользователь перенаправляется сервером к клиенту.
- Клиент передаёт серверу токен запроса посредством протокола TLS и запрашивает доступ к ресурсам.
- Сервер подтверждает запрос и отвечает клиенту новым токеном доступа (англ. Access Token).
- Используя токен доступа, клиент обращается к серверу за ресурсами.
- Сервер подтверждает запрос и предоставляет ресурсы.
OAuth 2.0
Протокол OAuth 2.0 обратно не совместим с протоколом OAuth 1.0[1]. Вместо того, чтобы дополнить OAuth 1.0, было принято решение разработать другой протокол[10]. Поэтому принцип работы OAuth 1.0 и OAuth 2.0 отличается. Так в стандарте OAuth 2.0 описаны следующие потоки (сценарии взаимодействия сторон)[1]:
- Поток неявного доступа (англ. Implicit Grant Flow)
- Является самым коротким потоком протокола: пользователь сначала перенаправляется клиентом на сервер, чтобы разрешить доступ к ресурсам, а после того, как доступ будет получен, перенаправляется сервером обратно к клиенту[10].
- Поток с кодом подтверждения (англ. Authorization Code Flow)
- Отличие данного потока от потока неявного доступа заключается в дополнительном шаге аутентификации клиента[10].
- Поток с обновляемым токеном (англ. Refreshing an Expired Access Token Flow)
- Отличия этого потока от приведённого примера в следующем: на шаге 2 сервер помимо токена доступа, который имеет ограниченное время жизни, выдаёт токен обновления; на шаге 8 сервер проверяет, является ли токен доступа валидным (в смысле истечения времени жизни), и в зависимости от этого либо предоставляет доступ к ресурсам, либо требует обновления токена доступа (который предоставляется при предъявлении токена обновления).
- Поток с предоставлением клиенту пароля (англ. Resource Owner Password Credentials Flow)
- В этом потоке владелец ресурсов предоставляет клиенту логин и пароль, он передаёт их серверу и получает токен для доступа к ресурсам. Несмотря на то, что такой режим работы несколько противоречит концепции создания протокола, он описан в спецификации.
- Поток клиентских полномочий (англ. Client Credentials Flow)
- В данном режиме работы протокола предоставление сервером токена доступа происходит после передачи клиентом его пользователя и пароля, который был предварительно установлен сервером авторизации (в спецификации не оговорено, каким именно образом). Фактически, клиент сразу проходит как авторизацию, так и аутентификацию.
OAuth поддерживает два метода
Примечания
- ↑ 1 2 3 4 5 D. Hardt, Ed. The OAuth 2.0 Authorization Framework. Introduction (англ.). Internet Engineering Task Force (октябрь 2012). Дата обращения: 30 октября 2015. Архивировано 14 мая 2016 года.
- ISSN 2070-1721. Архивировано3 ноября 2016 года.
- ↑ 1 2 3 4 5 6 Gibbons K., Raw J. O., Curran K. Security Evaluation of the OAuth 2.0 Framework (англ.) // Information Management and Computer Security — Emerald Publishing Limited, 2014. — Vol. 22, Iss. 3. — ISSN 0968-5227; 1758-5805
- ↑ 1 2 3 Eran Hammer. The OAuth 1.0 Guide. History (англ.). Дата обращения: 30 октября 2015. Архивировано 25 октября 2015 года.
- ↑ Eran Hammer. Introducing OAuth 2.0 (англ.). hueniverse.com. Дата обращения: 30 октября 2015. Архивировано из оригинала 15 января 2011 года.
- ↑ 1 2 Ryan Boyd. Introduction // Getting Started with OAuth 2.0. — 1-е изд. — 1005 Gravenstein Highway North, Sebastopol: O’Reilly Media, Inc., 2012. — С. 67. — 9—12, 23—24 с. — ISBN 978-1-449-31160-5. Архивировано 21 ноября 2015 года.
- ↑ Eran Hammer. OAuth 2.0 and the Road to Hell (англ.). hueniverse (26 июля 2012). Дата обращения: 14 июня 2017. Архивировано из оригинала 25 марта 2013 года.
- ↑ Eran Hammer. OAuth 2.0 - Looking Back and Moving On (англ.). hueniverse. Дата обращения: 30 октября 2015. Архивировано 22 октября 2015 года.
- ↑ D. Hardt. The OAuth 2.0 Authorization Framework: Bearer Token Usage draft-ietf-oauth-v2-bearer-23. Appendix B. Document History (англ.) (1 августа 2012). Дата обращения: 30 октября 2015. Архивировано 16 ноября 2015 года.
- ↑ 1 2 3 4 5 6 7 Chen E. Y., Pei Y., Chen S., Tian Y., Kotcher R., Tague P. OAuth Demystified for Mobile Application Developers (англ.) // Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security — New York City: ACM, 2014. — P. 892—903. — ISBN 978-1-4503-2957-6 — doi:10.1145/2660267.2660323
- ↑ Eran Hammer. Terminology (англ.). hueniverse. Дата обращения: 31 октября 2015. Архивировано 1 ноября 2015 года.
- ↑ 1 2 3 Eran Hammer. Security Framework (англ.). hueniverse. Дата обращения: 31 октября 2015. Архивировано 5 ноября 2015 года.
- ↑ 1 2 3 4 5 E. Hammer-Lahav, Ed. The OAuth 1.0 Protocol (англ.). Internet Engineering Task Force. Дата обращения: 8 ноября 2015. Архивировано 10 ноября 2015 года.
Ссылки
- oauth.net (англ.) — официальный сайт OAuth
Эта статья входит в число добротных статей русскоязычного раздела Википедии. |