OAuth - История изменений

Wikiadmin: /* Последующее развитие */

2020-12-12T12:17:11Z

Последующее развитие

Wikiadmin: /* OAuth 2.0 */

2020-12-12T12:16:34Z

OAuth 2.0

Wikiadmin: /* OAuth 1.0 */

2020-12-12T12:15:22Z

OAuth 1.0

Wikiadmin: /* Применение */

2020-12-12T12:14:47Z

Применение

Wikiadmin: /* Методы создания подписей */

2020-12-11T18:40:21Z

Методы создания подписей

Wikiadmin: /* OAuth 1.0 */

2020-12-11T18:39:49Z

OAuth 1.0

Wikiadmin: /* OAuth 2.0 */

2020-12-11T18:38:53Z

OAuth 2.0

Wikiadmin: /* OAuth 2.0 */

2020-12-11T18:37:03Z

OAuth 2.0

Wikiadmin: /* OAuth 2.0 */

2020-12-11T18:36:35Z

OAuth 2.0

Wikiadmin: /* OAuth 1.0 */

2020-12-11T18:35:24Z

OAuth 1.0

@@ Строка 29: / Строка 29: @@
 === Последующее развитие ===
-В июле 2012 года Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трёх лет работы над новым стандартом и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своём сайте и позже выступил с докладом. Дик Хардт (Dick Hardt) стал редактором стандарта OAuth2.0, и, несмотря на взгляды Эрана Хаммера, структура OAuth 2.0 была опубликована в RFC 6749 в октябре 2012 года.
+В июле 2012 года Эран Хаммер (Eran Hammer), действующий редактор стандарта OAuth 2.0, объявил об уходе с поста после трёх лет работы над новым стандартом и попросил вычеркнуть своё имя из спецификаций. Он говорил о своих взглядах на своём сайте и позже выступил с докладом. Девид Рекордон (англ. David Recordon) позже также вычеркнул своё имя из спецификаций без указания причин. Дик Хардт (Dick Hardt) стал редактором стандарта OAuth2.0, и, несмотря на взгляды Эрана Хаммера, структура OAuth 2.0 была опубликована в RFC 6749 в октябре 2012 года.
 == Сравнение с другими протоколами ==

@@ Строка 18: / Строка 18: @@
 === OAuth 2.0 ===
-В 2010 году началась работа над новой версией протокола OAuth 2.0, для которой не предусматривалась обратная совместимость с OAuth 1.0. В октябре [[2012 год]]а структура OAuth 2.0 была опубликована в RFC 6749, и использование носителя токена в RFC 6750.
+В 2010 году началась работа над новой версией протокола OAuth 2.0, для которой не предусматривалась обратная совместимость с OAuth 1.0. В октябре 2012 года структура OAuth 2.0 была опубликована в RFC 6749, и использование носителя токена в RFC 6750.
-Предпосылок для создания OAuth 2.0 было несколько.
+Предпосылок для создания OAuth 2.0 было несколько. В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth — упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трёх методов (называемых потоками (англ. flows)) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым. В него, помимо новых потоков, были добавлены:
-В первую очередь, OAuth достаточно нетривиально использовать на клиентской стороне. Одна из поставленных целей при разработке нового OAuth — упростить разработку клиентских приложений. Во-вторых, несмотря на заявленную в стандарте реализацию трёх методов (называемых потоками (flows) получения токена (уникального идентификатора) для авторизации: для веб-приложений, настольных клиентов и мобильных клиентов, фактически все три способа слиты в один. И, в-третьих, протокол оказался плохо масштабируемым.
-В него, помимо новых потоков, были добавлены:
+*Токен на предъявителя. Метод авторизации аналогичен существующему способу авторизации с помощью cookie. В этом случае токен непосредственно используется как секрет (сам факт наличия токена авторизует клиента) и передаётся через HTTPS. Это позволяет получать доступ к API посредством простых скриптов (например, с использованием cURL).
-* ''Токен на предъявителя''. Метод авторизации аналогичен существующему способу авторизации с помощью [[HTTP-Cookie|cookie]]. В этом случае токен непосредственно используется как секрет (сам факт наличия токена авторизует клиента) и передаётся через [[HTTPS]]. Это позволяет получать доступ к API посредством простых скриптов (например, с использованием [[cURL]]).
+*Упрощенная подпись. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
-* ''Упрощенная подпись''. Подпись была значительно упрощена, чтобы устранить необходимость в специальном анализе, кодированиях и сортировках параметров.
+*Короткоживущие токены с долговременной авторизацией. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
-* ''Короткоживущие токены с долговременной авторизацией''. Вместо выдачи долгоживущего токена (который за длительное время может быть скомпрометирован), сервер предоставляет кратковременный доступ и долговременную возможность обновлять токен без участия пользователя.
+*Разделение ролей. За авторизацию и за предоставление доступа к API могут отвечать разные сервера.
-* ''Разделение ролей''. За авторизацию и за предоставление доступа к API могут отвечать разные сервера.
+Несмотря на то, что стандарт OAuth 2.0 не утверждён, он используется некоторыми сервисами. Так, авторизация в Mail.Ru API переведена на стандарт OAuth 2.0, Facebook Graph API (англ.)русск. поддерживает только OAuth 2.0., а Google рассматривает OAuth 2.0 как рекомендательный механизм аутентификации для всех своих API.
 === Последующее развитие ===

@@ Строка 11: / Строка 11: @@
 === OAuth 1.0 ===
-OAuth появился в ноябре 2006 года, во время разработки протокола [[OpenID]] для сервиса микроблогов [[Twitter]]. Совместно с он искал способ использования OpenID для доступа к [[Twitter]] [[API]] без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как [[Flickr Auth]], [[Google AuthSub]] и [[Yahoo! BBAuth]], после чего пришли к заключению, что существует необходимость в новом открытом протоколе<ref name="The OAuth 1.0 Guide. History".
+OAuth появился в ноябре 2006 года, во время разработки Блейном Куком (англ. Blaine Cook) протокола OpenID для сервиса микроблогов Twitter. Совместно с Крисом Мессиной (англ. Chris Messina) он искал способ использования OpenID для доступа к Twitter API без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID Девидом Рекордоном (англ. David Recordon) они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как Flickr Auth, Google AuthSub и Yahoo! BBAuth, после чего пришли к заключению, что существует необходимость в новом открытом протоколе.
-В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний Google и AOL (которая в это же время представила свой собственный протокол [[OpenAuth]]).
+В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний Google и AOL (которая в это же время представила свой собственный протокол OpenAuth). Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в Инженерном совете Интернета.
-апреля 2009 года Twitter предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Твиттер» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней была обнаружена потенциальная уязвимость, затрагивающая все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновлённую спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня. В апреле [[2010 год]]а был выпущен информационный документ [[RFC]] 5849, посвящённый стандарту OAuth.
+апреля 2009 года Twitter предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Твиттер» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней была обнаружена потенциальная уязвимость, затрагивающая все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновлённую спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня. В апреле 2010 года был выпущен информационный документ RFC 5849, посвящённый стандарту OAuth.
 === OAuth 2.0 ===

@@ Строка 4: / Строка 4: @@
 == Применение ==
-Одной из проблем аутентификации и [[Информационная безопасность|информационной безопасности]] является тот факт, что у одного пользователя, как правило, имеется несколько учётных записей на различных сервисах (например, на Google, Twitter, Apple и др.). При этом человеку приходится для каждого из сервисов иметь отдельные логин и пароль. В то же время, каждый из сервисов имеет свою систему безопасности, каждая из которых имеет свои уязвимости и недостатки. Как следствие, пользователям нужно хранить и защищать множество логинов-паролей, что вредит как удобству, так и безопасности; когда, например, пользователи для разных сервисов начинают использовать одни и те же пароли. В то же время, в данных обстоятельствах злоумышленникам становится проще осуществлять взлом (например, после получения доступа к одной из учётных записей взлом других может быть облегчён).
+Одной из проблем аутентификации и информационной безопасности является тот факт, что у одного пользователя, как правило, имеется несколько учётных записей на различных сервисах (например, на Google, Twitter, Apple и др.). При этом человеку приходится для каждого из сервисов иметь отдельные логин и пароль. В то же время, каждый из сервисов имеет свою систему безопасности, каждая из которых имеет свои уязвимости и недостатки. Как следствие, пользователям нужно хранить и защищать множество логинов-паролей, что вредит как удобству, так и безопасности; когда, например, пользователи для разных сервисов начинают использовать одни и те же пароли. В то же время, в данных обстоятельствах злоумышленникам становится проще осуществлять взлом (например, после получения доступа к одной из учётных записей взлом других может быть облегчён).
-Для улучшения защиты может быть использована аутентификация в два шага (например [[Google Authenticator]]), когда для подтверждения задействуется другой сервис пользователя (например, когда для аутентификации на веб-сайте требуется ввести кодовое слово, отправляемое на мобильный телефон). В этом случае вероятность взлома значительно уменьшается. Ключевая особенность применения OAuth заключается в том, что, если пользователь имеет подобный хорошо защищённый аккаунт, то с его помощью и технологии OAuth он может пройти аутентификацию на других сервисах, и при этом ему не требуется раскрывать свой основной пароль. Например, пользователь, который хочет предоставить онлайн-сервису печати фотографий доступ к фотографиям своего [[Facebook|Facebook-аккаунта]], не должен сообщать сервису пароль от этого аккаунта. Вместо этого он проходит авторизацию непосредственно в Facebook’е, который (с разрешения пользователя или администратора сервиса) предоставляет сервису онлайн-печати полномочия доступа к фотографиям.
+Для улучшения защиты может быть использована аутентификация в два шага (например Google Authenticator), когда для подтверждения задействуется другой сервис пользователя (например, когда для аутентификации на веб-сайте требуется ввести кодовое слово, отправляемое на мобильный телефон). В этом случае вероятность взлома значительно уменьшается. Ключевая особенность применения OAuth заключается в том, что, если пользователь имеет подобный хорошо защищённый аккаунт, то с его помощью и технологии OAuth он может пройти аутентификацию на других сервисах, и при этом ему не требуется раскрывать свой основной пароль. Например, пользователь, который хочет предоставить онлайн-сервису печати фотографий доступ к фотографиям своего Facebook-аккаунта, не должен сообщать сервису пароль от этого аккаунта. Вместо этого он проходит авторизацию непосредственно в Facebook’е, который (с разрешения пользователя или администратора сервиса) предоставляет сервису онлайн-печати полномочия доступа к фотографиям.
 == История ==

@@ Строка 57: / Строка 57: @@
 === Методы создания подписей ===
-OAuth поддерживает 3 метода создания подписей, используемых для подписывания и проверки запросов: [[Plain text|PLAINTEXT]], [[HMAC]]-[[SHA1]] и [[RSA]]-[[SHA1]]. [[Plain text|PLAINTEXT]] тривиален в использовании и занимает значительно меньше времени для вычисления, но он может быть безопасен только над [[HTTPS]] или аналогичными защищёнными каналами. [[HMAC]]-[[SHA1]] предлагает простой и общий алгоритм, который доступен на большинстве платформ, но не на всех устаревших устройствах, и использует симметричный общий ключ. [[RSA]]-[[SHA1]] обеспечивает повышенную безопасность с помощью пары ключей, но является более сложным и требует генерации ключей<ref name="Security Framework">{{cite web
+OAuth поддерживает 3 метода создания подписей, используемых для подписывания и проверки запросов: [[Plain text|PLAINTEXT]], [[HMAC]]-[[SHA1]] и [[RSA]]-[[SHA1]]. [[Plain text|PLAINTEXT]] тривиален в использовании и занимает значительно меньше времени для вычисления, но он может быть безопасен только над [[HTTPS]] или аналогичными защищёнными каналами. [[HMAC]]-[[SHA1]] предлагает простой и общий алгоритм, который доступен на большинстве платформ, но не на всех устаревших устройствах, и использует симметричный общий ключ. [[RSA]]-[[SHA1]] обеспечивает повышенную безопасность с помощью пары ключей, но является более сложным и требует генерации ключей.
 === Метка времени и Nonce ===

@@ Строка 158: / Строка 158: @@
 Протокол OAuth 2.0 обратно не совместим с протоколом OAuth 1.0. Вместо того, чтобы дополнить OAuth 1.0, было принято решение разработать другой протокол. Поэтому принцип работы OAuth 1.0 и OAuth 2.0 отличается. Так в стандарте OAuth 2.0 описаны следующие потоки (сценарии взаимодействия сторон):
 * Поток неявного доступа (Implicit Grant Flow)
-: Является самым коротким потоком протокола: пользователь сначала перенаправляется клиентом на сервер, чтобы разрешить доступ к ресурсам, а после того, как доступ будет получен, перенаправляется сервером обратно к клиенту{{source-ref|Q21694381}}.
+: Является самым коротким потоком протокола: пользователь сначала перенаправляется клиентом на сервер, чтобы разрешить доступ к ресурсам, а после того, как доступ будет получен, перенаправляется сервером обратно к клиенту.
 * Поток с кодом подтверждения (Authorization Code Flow)
 : Отличие данного потока от потока неявного доступа заключается в дополнительном шаге аутентификации клиента.

@@ Строка 156: / Строка 156: @@
 === OAuth 2.0 ===
-Протокол OAuth 2.0 обратно не совместим с протоколом OAuth 1.0<ref name=rfc6749 />. Вместо того, чтобы дополнить OAuth 1.0, было принято решение разработать другой протокол{{source-ref|Q21694381}}. Поэтому принцип работы OAuth 1.0 и OAuth 2.0 отличается. Так в стандарте OAuth 2.0 описаны следующие потоки (сценарии взаимодействия сторон)<ref name=rfc6749 />:
+Протокол OAuth 2.0 обратно не совместим с протоколом OAuth 1.0. Вместо того, чтобы дополнить OAuth 1.0, было принято решение разработать другой протокол. Поэтому принцип работы OAuth 1.0 и OAuth 2.0 отличается. Так в стандарте OAuth 2.0 описаны следующие потоки (сценарии взаимодействия сторон):
-* Поток неявного доступа ({{lang-en|Implicit Grant Flow}})
+* Поток неявного доступа (Implicit Grant Flow)
 : Является самым коротким потоком протокола: пользователь сначала перенаправляется клиентом на сервер, чтобы разрешить доступ к ресурсам, а после того, как доступ будет получен, перенаправляется сервером обратно к клиенту{{source-ref|Q21694381}}.
-* Поток с кодом подтверждения ({{lang-en|Authorization Code Flow}})
+* Поток с кодом подтверждения (Authorization Code Flow)
 : Отличие данного потока от потока неявного доступа заключается в дополнительном шаге аутентификации клиента.
-* Поток с обновляемым токеном ({{lang-en|Refreshing an Expired Access Token Flow}})
+* Поток с обновляемым токеном (Refreshing an Expired Access Token Flow)
 : Отличия этого потока от приведённого примера в следующем: на шаге 2 сервер помимо токена доступа, который имеет ограниченное время жизни, выдаёт токен обновления; на шаге 8 сервер проверяет, является ли токен доступа валидным (в смысле истечения времени жизни), и в зависимости от этого либо предоставляет доступ к ресурсам, либо требует обновления токена доступа (который предоставляется при предъявлении токена обновления).
-* Поток с предоставлением клиенту пароля ({{lang-en|Resource Owner Password Credentials Flow}})
+* Поток с предоставлением клиенту пароля (Resource Owner Password Credentials Flow)
 : В этом потоке владелец ресурсов предоставляет клиенту логин и пароль, он передаёт их серверу и получает токен для доступа к ресурсам. Несмотря на то, что такой режим работы несколько противоречит концепции создания протокола, он описан в спецификации.
-* Поток клиентских полномочий ({{lang-en|Client Credentials Flow}})
+* Поток клиентских полномочий (Client Credentials Flow)
 : В данном режиме работы протокола предоставление сервером токена доступа происходит после передачи клиентом его пользователя и пароля, который был предварительно установлен сервером авторизации (в спецификации не оговорено, каким именно образом). Фактически, клиент сразу проходит как авторизацию, так и аутентификацию.
-OAuth поддерживает два метода [[аутентификация|аутентификации]] сообщений от клиента: [[HMAC]]-[[SHA1]] и [[RSA]]-[[SHA1]]. Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «[[plain text]]». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол [[SSL]] или [[TLS]]<ref name="RFC" />.
+OAuth поддерживает два метода [[аутентификация|аутентификации]] сообщений от клиента: [[HMAC]]-[[SHA1]] и [[RSA]]-[[SHA1]]. Есть возможность передавать сообщения без подписи, тогда в поле типа подписи указывается «[[plain text]]». Но в этом случае, согласно спецификации, соединение между клиентом и сервером должно устанавливаться через протокол [[SSL]] или [[TLS]].
 == Ссылки ==

@@ Строка 11: / Строка 11: @@
 === OAuth 1.0 ===
-OAuth появился в ноябре 2006 года, во время разработки протокола [[OpenID]] для сервиса микроблогов [[Twitter]]. Совместно с он искал способ использования OpenID для доступа к [[Twitter]] [[API]] без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как [[Flickr Auth]], [[Google AuthSub]] и [[Yahoo! BBAuth]], после чего пришли к заключению, что существует необходимость в новом открытом протоколе<ref name="The OAuth 1.0 Guide. History">{{cite web
+OAuth появился в ноябре 2006 года, во время разработки протокола [[OpenID]] для сервиса микроблогов [[Twitter]]. Совместно с он искал способ использования OpenID для доступа к [[Twitter]] [[API]] без предоставления сервису пароля. В сотрудничестве с одним из создателей OpenID они провели анализ функциональности OpenID, а также проприетарных протоколов авторизации, таких как [[Flickr Auth]], [[Google AuthSub]] и [[Yahoo! BBAuth]], после чего пришли к заключению, что существует необходимость в новом открытом протоколе<ref name="The OAuth 1.0 Guide. History".
 В апреле 2007 года образовалась группа инженеров, работавших над его созданием. В её работе приняли участие сотрудники компаний [[Google (компания)|Google]] и [[AOL]] (которая в это же время представила свой собственный протокол [[OpenAuth]]).
-Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в [[IETF|Инженерном совете Интернета]]<ref name="The OAuth 1.0 Guide. History" />.
+Финальная версия ядра протокола OAuth 1.0 была представлена 4 декабря 2007 года. В 2008 году проводилась работа по стандартизации протокола в [[IETF|Инженерном совете Интернета]].
-апреля 2009 года [[Twitter]] предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Твиттер» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней была обнаружена потенциальная уязвимость, затрагивающая все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновлённую спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня. В апреле [[2010 год]]а был выпущен информационный документ [[RFC]] 5849<ref name="RFC">{{cite web
+апреля 2009 года [[Twitter]] предложил своим пользователям решение, позволяющее делегировать третьесторонним сайтам и сервисам доступ к своим аккаунтам. Оно было названо «Войти через Твиттер» и было основано на OAuth. Это событие стало поводом для первого широкого исследования протокола на уязвимости, и через несколько дней была обнаружена потенциальная уязвимость, затрагивающая все существующие реализации OAuth. После этого, 23 апреля сообществом разработчиков было выпущено первое дополнение безопасности к протоколу, которое вошло в обновлённую спецификацию OAuth Core 1.0 Revision A, опубликованную 24 июня. В апреле [[2010 год]]а был выпущен информационный документ [[RFC]] 5849, посвящённый стандарту OAuth.
 === OAuth 2.0 ===