Социальные сети входят в нашу жизнь все глубже и глубже. Зачастую для многих это является и средством заработка, и основным инструментом работы. Бывает и такие случаи, когда одному сайту требуется ваша личная информация с другого, например, автоматический постинг в Twitter из Bitly. Чтобы такой процесс состоялся, вы должны раскрыть свой логин и пароль от одного ресурса другому. Это не верный путь. Верный – они должны использовать OAuth.
OAuth — открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль.
Это краткое руководство иллюстрирует, как можно проще, то как OAuth работает.
Участники
В транзакциях OAuth участвуют 3 основных участника: пользователь, потребитель и поставщик услуг. Этот триумвират можно ласково назвать любовным треугольником OAuth.
В нашем примере Джо – пользователь, Bitly – потребитель, а Twitter – поставщик, который контролирует защищенные ресурсы Джо (его лента). Джо хочет, чтобы Bitly публиковал укороченных ссылок в его ленту. Вот как это работает:
Шаг 1 — пользователь изъявляет желание
Джо (пользователь): «Привет, Bitly, я хочу, чтобы ты публиковал свои ссылки непосредственно в мою ленту.»
Bitly (Потребитель): «Нет проблем! Пойду спрошу разрешения.»
Шаг 2 — Потребитель получает разрешение
Bitly: «У меня тут есть пользователь, который хочет, чтобы я публиковал в его поток. Можно мне маркер запроса? »
Twitter (поставщик): «Хорошо. Вот тебе токен и секретное слово, никому его не говори.»
Секрет используется для предотвращения подделки запросов. Потребитель использует его для подписи каждого своего запроса, чтобы поставщик мог проверить, что запросы идут действительно из приложения-потребителя.
Шаг 3 — Пользователь перенаправляется к поставщику услуг
Bitly: «ОК, Джо. Я вас на Twitter пошлю, нужно чтобы вы там подтвердили. Токен возьми с собой.»
Джо: «Согласен!»
<Bitly перенаправляет Джо Twitter для авторизации>
Шаг 4 — пользователь дает разрешение
Джо: «Twitter, я бы хотел, чтобы ты авторизовал вот этот маркер, мне его дал Bitly.»
Twitter: «Хорошо, просто чтобы быть уверенным, вы хотите разрешить Bitly делать то, это и вон то? »
Джо: «Да!»
Twitter: «Хорошо, вы можете передать Bitly, что им можно пользоваться маркером запроса »
Twitter помечает данный маркер как подтвержденный, так что, когда пользователь будет запросит доступ, он его получит (до тех пор, пока он подписан их общим секретным словом).
Шаг 5 — Потребитель получает маркер доступа
Bitly: «Twitter, могу ли я поменять маркер запроса на маркер доступа?»
Twitter: «Конечно. Вот тебе маркер доступа и секретное слово.»
Шаг 6 — Доступ потребителя к защищаемому ресурсу
Bitly: «Twitter, я хотел бы опубликовать ссылку в ленту Джо. Вот мой маркер доступа.»
Twitter: «Маркер действителен. Готово!»
Вывод
В нашем сценарии Джо не пришлось делиться своими данными учетной записи Twitter с Bitly. Он просто делегировал доступ с помощью OAuth в безопасном режиме. В любой момент Джо может войти в свой аккаунт Twitter и пересмотреть все доступы, которые он разрешил и, в случае необходимости, отозвать любой из них. OAuth позволяет разделить доступ по разным уровням. Вы можете дать право Bitly публиковать, но дать разрешение только на чтение для LinkedIn.
OAuth не совершенен… пока что
OAuth представляет собой сильное решение для web-приложений и это огромный шаг вперед по сравнению с обычной HTTP аутентификацией. Тем не менее существуют определенные ограничения, в частности в OAuth 1.0.
OAuth 2.0 более новая и безопасная версия протокола, в которой появились различные «потоки» информации для web, мобильных и настольных приложений. В нем так же присутствует понятие истечения срока действия маркера (по аналогии с cookies), работает поверх SSL и уменьшает сложность разработки, беря на себя процедуры сложных аутентификаций.
Дополнительные источники
Надеюсь это был хороший пример, который дал понятие о OAuth «в общих чертах». Поэтому, когда вы следующий раз увидите кнопку «Вход с помощью Twitter» или подобную, вы будете иметь представление о том, что происходит при ее нажатии.
Если вы хотите погрузиться глубже в механику работы, вот некоторые полезные ссылки:
• hueniverse.com/oauth
• marktrapp.com/blog/2009/09/17/oauth-dummies
• dev.twitter.com/docs/auth/oauth/faq
• stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1
• googlecodesamples.com/oauth_playground
• www.justin.tv/hackertv/b/259433315
OAuth — открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищённым ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль.
Это краткое руководство иллюстрирует, как можно проще, то как OAuth работает.
Участники
В транзакциях OAuth участвуют 3 основных участника: пользователь, потребитель и поставщик услуг. Этот триумвират можно ласково назвать любовным треугольником OAuth.
В нашем примере Джо – пользователь, Bitly – потребитель, а Twitter – поставщик, который контролирует защищенные ресурсы Джо (его лента). Джо хочет, чтобы Bitly публиковал укороченных ссылок в его ленту. Вот как это работает:
Шаг 1 — пользователь изъявляет желание
Джо (пользователь): «Привет, Bitly, я хочу, чтобы ты публиковал свои ссылки непосредственно в мою ленту.»
Bitly (Потребитель): «Нет проблем! Пойду спрошу разрешения.»
Шаг 2 — Потребитель получает разрешение
Bitly: «У меня тут есть пользователь, который хочет, чтобы я публиковал в его поток. Можно мне маркер запроса? »
Twitter (поставщик): «Хорошо. Вот тебе токен и секретное слово, никому его не говори.»
Секрет используется для предотвращения подделки запросов. Потребитель использует его для подписи каждого своего запроса, чтобы поставщик мог проверить, что запросы идут действительно из приложения-потребителя.
Шаг 3 — Пользователь перенаправляется к поставщику услуг
Bitly: «ОК, Джо. Я вас на Twitter пошлю, нужно чтобы вы там подтвердили. Токен возьми с собой.»
Джо: «Согласен!»
<Bitly перенаправляет Джо Twitter для авторизации>
Шаг 4 — пользователь дает разрешение
Джо: «Twitter, я бы хотел, чтобы ты авторизовал вот этот маркер, мне его дал Bitly.»
Twitter: «Хорошо, просто чтобы быть уверенным, вы хотите разрешить Bitly делать то, это и вон то? »
Джо: «Да!»
Twitter: «Хорошо, вы можете передать Bitly, что им можно пользоваться маркером запроса »
Twitter помечает данный маркер как подтвержденный, так что, когда пользователь будет запросит доступ, он его получит (до тех пор, пока он подписан их общим секретным словом).
Шаг 5 — Потребитель получает маркер доступа
Bitly: «Twitter, могу ли я поменять маркер запроса на маркер доступа?»
Twitter: «Конечно. Вот тебе маркер доступа и секретное слово.»
Шаг 6 — Доступ потребителя к защищаемому ресурсу
Bitly: «Twitter, я хотел бы опубликовать ссылку в ленту Джо. Вот мой маркер доступа.»
Twitter: «Маркер действителен. Готово!»
Вывод
В нашем сценарии Джо не пришлось делиться своими данными учетной записи Twitter с Bitly. Он просто делегировал доступ с помощью OAuth в безопасном режиме. В любой момент Джо может войти в свой аккаунт Twitter и пересмотреть все доступы, которые он разрешил и, в случае необходимости, отозвать любой из них. OAuth позволяет разделить доступ по разным уровням. Вы можете дать право Bitly публиковать, но дать разрешение только на чтение для LinkedIn.
OAuth не совершенен… пока что
OAuth представляет собой сильное решение для web-приложений и это огромный шаг вперед по сравнению с обычной HTTP аутентификацией. Тем не менее существуют определенные ограничения, в частности в OAuth 1.0.
OAuth 2.0 более новая и безопасная версия протокола, в которой появились различные «потоки» информации для web, мобильных и настольных приложений. В нем так же присутствует понятие истечения срока действия маркера (по аналогии с cookies), работает поверх SSL и уменьшает сложность разработки, беря на себя процедуры сложных аутентификаций.
Дополнительные источники
Надеюсь это был хороший пример, который дал понятие о OAuth «в общих чертах». Поэтому, когда вы следующий раз увидите кнопку «Вход с помощью Twitter» или подобную, вы будете иметь представление о том, что происходит при ее нажатии.
Если вы хотите погрузиться глубже в механику работы, вот некоторые полезные ссылки:
• hueniverse.com/oauth
• marktrapp.com/blog/2009/09/17/oauth-dummies
• dev.twitter.com/docs/auth/oauth/faq
• stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1
• googlecodesamples.com/oauth_playground
• www.justin.tv/hackertv/b/259433315
Поделиться с друзьями
Комментарии (7)
evz
12.05.2016 16:27-2Есть не большая опечатка «вперед по сравнению с обысной HTTP аутентификацией» пожалуйста исправьте.
novoxudonoser
12.05.2016 22:26+1ММм… Если бы в заголовке написать не "(в простых словах)", а "(в двух словах)" былобы понятней, хотя как по мне так лучше использовать "(в пол слова)"
hopeandskate
13.05.2016 18:10OAuth 2.0 конечно намного удобнее чем первая версия. Делал приложение, чтобы новости Твиттера и Вконтакте была в одной ленте, после легкой авторизации Вконтакте, я ужаснулся от Твиттера )
12sd
13.05.2016 18:10OAuth задумывался как единый протокол авторизации, а получилось… у каждого провайдера свои нюансы имплементации.
В итоге имеем целый ворох разных версий, в котором порой весьма непросто разобраться.
hueniversedotcom.files.wordpress.com/2012/07/oauthdead.jpg
grossws
Стоит явно указывать о какой версии протокола идёт речь. Предыдущие статьи по OAuth и OAuth2 от других авторов были куда лучше и подробнее.
Перевод терминологии — откровенное говно ибо спутаны state/nonce, authorization_code и access_token. Также слово потребитель (которое в спеке client) вносит дополнительную путаницу.