Журнал LinuxFormat - перейти на главную

LXF150:OAuth

Материал из Linuxformat
Перейти к: навигация, поиск

Что за штука… 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/.
Персональные инструменты
купить
подписаться
Яндекс.Метрика