LXF150:OAuth

Подписка на печатную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подписка на электронную версию Весь 2015 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Подшивки старых номеров журнала (печатные версии) Весь 2014 год (12 номеров) Первое полугодие (6 номеров) Второе полугодие (6 номеров)

Что за штука… 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/.