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/.
