LXF150:OAuth

Текущая версия на 16:28, 2 сентября 2014 (просмотреть исходный код) 2sash-kan (обсуждение | вклад) (Новая страница: «==Что за штука… OAuth?== :'''Марко Фиоретти''' объясняет, как сэкономить время и остаться в без…»)

---

Текущая версия на 16:28, 2 сентября 2014

[править] Что за штука… OAuth?

Марко Фиоретти объясняет, как сэкономить время и остаться в безопасности, авторизировав сайты поработать за вас.

В 

Рассказывайте, но желательно — покороче.

О

OAuth (http://OAuth.net/http://OAuth.net/) – это протокол аутентификации и авторизации, изначально разработанный для web-приложений и возникший в недрах Twitter в 2006 году.

В

Ладно, значит, это не фантомный продукт; и что он делает?

О

Он позволяет стороннему ПО выступать от вашего имени, на ограниченный срок и без передачи этому ПО постоянного или полного доступа к приватной информации.

В

Типа ключей, передаваемых работникам автосервиса?

О

Да. С их помощью можно открыть, завести машину и проехать, но недалеко и не открывая багажник. Так и OAuth – своеобразный валет-ключ для ваших данных. Он предоставляет временный и ограниченный доступ к чему-то вашему, не отдавая при этом полного контроля.

В

Так, с этим понятно, но... такая ли уж это насущная задача?

О

Стала таковой, с тех пор как всевозможные онлайн-сервисы и социальные сети, от Twitter и Flickr до интернет-банков, сделались не просто вездесущими, но и взаимосвязанными – и гораздо более полезными, когда эта взаимосвязь работает на вас.

В

К примеру, если вам нужно разместить свою галерею Fliсkr на Facebook.

О

Точно. И то, что при этом не нужно вводить все заново вручную – просто здорово. Между тем, делать это без помощи OAuth или чего-то подобного – значит предоставлять этим сайтам полный доступ ко всему вашему контенту (то есть файлам, адресной книге, или же пользованию услугами).

В

Поэтому вы и упоминали и аутентификацию, и авторизацию?

О

Верно. Аутентификация – это способ доказать, что вы – это действительно ВЫ. Заметьте, что в принципе безразлично, являетесь ли «вы» человеком или программой. А авторизация – самостоятельная и не менее важная функция. Если некто или нечто подтвердили в Facebook свою личность, это еще не повод менять мой статус от моего имени.

В

А нельзя использовать для этой цели OpenID?

О

OpenID – это чистая аутентификация. А OAuth, напротив, нужен в тех случаях, когда (пользуясь внутренней терминологией) некая программа (клиент) хочет получить доступ к данным от имени лица с правом авторизации (владельца ресурса), будучи совершенно не известной и независимой по отношению к программе или сервису, где хранится ресурс.

В

Секунду! Это же было возможно задолго до OAuth!

О

Да, но в большинстве случаев речь шла либо об использовании всего одной учетной записи в сети уже взаимодействующих сайтов, либо о предоставлении по крайней мере одному их них ваших логинов и паролей для других. OAuth пытается закрыть эту лазейку в безопасности.

В

Вы говорите об авторизованном доступе к содержимому учетной записи, без сообщения моего пароля и логина?

О

Предположим, вы оставили комментарий в каком-то блоге и хотите, чтобы блог переслал эту запись в Twitter от вашего имени, вместо того, чтобы перепечатывать. Когда вы сообщаете об этом блогу (например, нажав кнопку), он направляет запрос в Twitter, включающий идентификационный ключ и те данные или функции, которыми он хочет воспользоваться от вашего имени. Twitter (а не блог!) предоставляет вам пользовательскую web-форму авторизации, размещенную на его сервере. Если вы успешно авторизуетесь в Twitter и подтвердите запрос, Twitter удовлетворит запрос блога. Без передачи вашего пароля и имени пользователя.

В

Да, это круто! А что будет происходить

потом?

О

Twitter вернет вас в браузере назад в блог, но уже со специальной ссылкой, содержащей «маркер доступа» или ключ однократной авторизации. Теперь блог сможет представить этот ключ Twitter в подтверждение того, что именно он только что получил разрешение на использование вашей учетной записи или ее изменение.

В

И это будет работать на любом сайте, поддерживающем OAuth, не только на Twitter?

О

Безусловно. Если, конечно, эти сайты не отклоняют первоначальный запрос. Помимо удобства для конечного пользователя, еще один мощным стимулом для OAuth было усложнить жизнь спам-ботам и другим вредоносным программам.

В

Каким образом у него может такое получиться?

О

Независимо от процедуры авторизации, программа может работать как описано выше только в том случае, если это разрешено сайтом, к которому она пытается получить доступ. В OAuth это достигается путем использования нескольких идентификационных ключей, или верительных реквизитов, параллельно.

В

Что это за реквизиты и кто, собственно, их выдает?

О

Те, о которых мы уже говорили: данные, предоставляющие какой-либо программе доступ без выдачи пароля, называются реквизитами доступа. Но перед этим клиент должен сообщить серверу достоверные учетные данные. Как правило, они предоставляются самим web-сервером. Когда разработчики ПО желают использовать OAuth, они регистрируются на сервере для получения этих реквизитов, или ключей. Таким образом стало немного проще бороться с некоторыми вредоносными программами, но также привело к сбоям в работе многих действующих.

В

Вы все время говорите о сайтах. Значит ли это, что OAuth неприменим к настольному ПО?

О

Вот это каверзный вопрос. Технически, ничто не мешает клиентам OAuth быть обычными настольными приложениями внутри вашего компьютера. На практике же (по крайней мере с OAuth 1.0), это значило либо осложнить жизнь добросовестным разработчикам, либо сделать всю систему реквизитов доступа почти бесполезной. Особенно если речь идет об Open Source.

В

Фу! Разумеется, хорошего тут мало, но почему это так?

О

Потому что схема, которую я описал, превосходно работает в том случае, если реквизиты прописаны в исходном коде и/или компилированной программе, работающей только на web-сервере, где нельзя прочитать эти реквизиты в самом коде, или же, посредством шестнадцатеричных редакторов и им подобных, в исполняемых файлах программы.

В

Так вот почему с открытым ПО проблема еще больше?

О

Именно. Если вы включаете что-то заведомо конфиденциальное в исходный код, который может скачать и изучить любой... оно уже не конфиденциально по определению, не так ли?

В

Конечно, но тут речь идет только о меньшей эффективности существующей схемы. А почему вы упоминали, что OAuth «ломает» существующее ПО?

О

Потому что до OAuth 1.0, любой человек, минимально знакомый с написанием скриптов оболочки и с URL (к таковым причисляется, между прочим, ваш покорный слуга!), мог за пару минут создать нечто, позволяющее автоматически зарегистрироваться в Twitter, прочитать ленту или создать пост. С появлением OAuth это стало невозможно без предоставления достоверных, зарегистрированных реквизитов доступа. Даже если получать эти реквизиты приходится дольше, чем писать скрипт!

В

А нельзя ли как-то исправить эти скрипты?

О

Конечно, можно: достаточно использовать всего одну из многочисленных библиотек ПО, которые уже зарегистрированы. Однако процесс написания и поддержки сценариев все равно останется более сложным, чем раньше. По крайней мере до выхода OAuth 2.0

В

Ага, значит, ожидается версия 2.0? А когда?

О

На данный момент, планируется, что OAuth 2.0 будет готов к концу 2011.

В

Что нового в OAuth 2.0? Решит ли он эти проблемы?

О

Возможно. Одним из главных изменений является добавление или переопределение так называемых «потоков» [flows] для ускорения получения реквизитов доступа, даже если клиент является не web-сервером, а, к примеру, приложением на мобильном устройстве. Предусмотрен также поток на основе cookies, позволяющий оживить старые скрипты, использующие cURL. Ожидается также и повышение производительности, поскольку OAuth 1.0 не очень хорошо масштабируется.

В

Где можно получить дополнительную информацию?

О

Официальное представление OAuth – на сайте http://OAuth.net/about/ или http://hueniverse.com/2010/05/introducing-OAuth-2-0/.