http://wiki.linuxformat.ru/wiki/index.php?action=history&feed=atom&title=LXF150%3AOAuth 2026-05-13T01:17:52Z История изменений этой страницы в вики MediaWiki 1.19.20+dfsg-0+deb7u3 http://wiki.linuxformat.ru/wiki/index.php?title=LXF150:OAuth&diff=15516&oldid=prev 2014-09-02T13:28:12Z

<p>Новая страница: «==Что за штука… OAuth?== :&#039;&#039;&#039;Марко Фиоретти&#039;&#039;&#039; объясняет, как сэкономить время и остаться в без…»</p> <p><b>Новая страница</b></p><div>==Что за штука… OAuth?==<br /> <br /> :'''Марко Фиоретти''' объясняет, как сэкономить время и остаться в безопасности, авторизировав сайты поработать за вас.<br /> <br /> ;В :Рассказывайте, но желательно — покороче.<br /> <br /> ;О<br /> <br /> :OAuth (http://OAuth.net/http://OAuth.net/) – это протокол аутентификации и авторизации, изначально разработанный для web-приложений и возникший в недрах Twitter в 2006 году.<br /> <br /> ;В<br /> <br /> :Ладно, значит, это не фантомный продукт; и что он делает?<br /> <br /> ;О<br /> <br /> :Он позволяет стороннему ПО выступать от вашего имени, на ограниченный срок и без передачи этому ПО постоянного или полного доступа к приватной информации.<br /> <br /> ;В<br /> <br /> :Типа ключей, передаваемых работникам автосервиса?<br /> <br /> ;О<br /> <br /> :Да. С их помощью можно открыть, завести машину и проехать, но недалеко и не открывая багажник. Так и OAuth – своеобразный валет-ключ для ваших данных. Он предоставляет временный и ограниченный доступ к чему-то вашему, не отдавая при этом полного контроля.<br /> <br /> ;В<br /> <br /> :Так, с этим понятно, но... такая ли уж это насущная задача?<br /> <br /> ;О<br /> <br /> :Стала таковой, с тех пор как всевозможные онлайн-сервисы и социальные сети, от Twitter и Flickr до интернет-банков, сделались не просто вездесущими, но и взаимосвязанными – и гораздо более полезными, когда эта взаимосвязь работает на вас.<br /> <br /> ;В<br /> <br /> :К примеру, если вам нужно разместить свою галерею Fliсkr на Facebook.<br /> <br /> ;О<br /> <br /> :Точно. И то, что при этом не нужно вводить все заново вручную – просто здорово. Между тем, делать это без помощи OAuth или чего-то подобного – значит предоставлять этим сайтам полный доступ ко всему вашему контенту (то есть файлам, адресной книге, или же пользованию услугами).<br /> <br /> ;В<br /> <br /> :Поэтому вы и упоминали и аутентификацию, и авторизацию?<br /> <br /> ;О<br /> <br /> :Верно. Аутентификация – это способ доказать, что вы – это действительно ВЫ. Заметьте, что в принципе безразлично, являетесь ли «вы» человеком или программой. А авторизация – самостоятельная и не менее важная функция. Если некто или нечто подтвердили в Facebook свою личность, это еще не повод менять мой статус от моего имени.<br /> <br /> ;В<br /> <br /> :А нельзя использовать для этой цели OpenID?<br /> <br /> ;О<br /> <br /> :OpenID – это чистая аутентификация. А OAuth, напротив, нужен в тех случаях, когда (пользуясь внутренней терминологией) некая программа (клиент) хочет получить доступ к данным от имени лица с правом авторизации (владельца ресурса), будучи совершенно не известной и независимой по отношению к программе или сервису, где хранится ресурс.<br /> <br /> ;В<br /> <br /> :Секунду! Это же было возможно задолго до OAuth!<br /> <br /> ;О<br /> <br /> :Да, но в большинстве случаев речь шла либо об использовании всего одной учетной записи в сети уже взаимодействующих сайтов, либо о предоставлении по крайней мере одному их них ваших логинов и паролей для других. OAuth пытается закрыть эту лазейку в безопасности.<br /> <br /> ;В<br /> <br /> :Вы говорите об авторизованном доступе к содержимому учетной записи, без сообщения моего пароля и логина?<br /> <br /> ;О<br /> <br /> :Предположим, вы оставили комментарий в каком-то блоге и хотите, чтобы блог переслал эту запись в Twitter от вашего имени, вместо того, чтобы перепечатывать. Когда вы сообщаете об этом блогу (например, нажав кнопку), он направляет запрос в Twitter, включающий идентификационный ключ и те данные или функции, которыми он хочет воспользоваться от вашего имени. Twitter (а не блог!) предоставляет вам пользовательскую web-форму авторизации, размещенную на его сервере. Если вы успешно авторизуетесь в Twitter и подтвердите запрос, Twitter удовлетворит запрос блога. Без передачи вашего пароля и имени пользователя.<br /> <br /> ;В<br /> <br /> :Да, это круто! А что будет происходить<br /> потом?<br /> <br /> ;О<br /> <br /> :Twitter вернет вас в браузере назад в блог, но уже со специальной ссылкой, содержащей «маркер доступа» или ключ однократной авторизации. Теперь блог сможет представить этот ключ Twitter в подтверждение того, что именно он только что получил разрешение на использование вашей учетной записи или ее изменение.<br /> <br /> ;В<br /> <br /> :И это будет работать на любом сайте, поддерживающем OAuth, не только на Twitter?<br /> <br /> ;О<br /> <br /> :Безусловно. Если, конечно, эти сайты не отклоняют первоначальный запрос. Помимо удобства для конечного пользователя, еще один мощным стимулом для OAuth было усложнить жизнь спам-ботам и другим вредоносным программам.<br /> <br /> ;В<br /> <br /> :Каким образом у него может такое получиться?<br /> <br /> ;О<br /> <br /> :Независимо от процедуры авторизации, программа может работать как описано выше только в том случае, если это разрешено сайтом, к которому она пытается получить доступ. В OAuth это достигается путем использования нескольких идентификационных ключей, или верительных реквизитов, параллельно.<br /> <br /> ;В<br /> <br /> :Что это за реквизиты и кто, собственно, их выдает?<br /> <br /> ;О<br /> <br /> :Те, о которых мы уже говорили: данные, предоставляющие какой-либо программе доступ без выдачи пароля, называются реквизитами доступа. Но перед этим клиент должен сообщить серверу достоверные учетные данные. Как правило, они предоставляются самим web-сервером. Когда разработчики ПО желают использовать OAuth, они регистрируются на сервере для получения этих реквизитов, или ключей. Таким образом стало немного проще бороться с некоторыми вредоносными программами, но также привело к сбоям в работе многих действующих.<br /> <br /> ;В<br /> <br /> :Вы все время говорите о сайтах. Значит ли это, что OAuth неприменим к настольному ПО?<br /> <br /> ;О<br /> <br /> :Вот это каверзный вопрос. Технически, ничто не мешает клиентам OAuth быть обычными настольными приложениями внутри вашего компьютера. На практике же (по крайней мере с OAuth 1.0), это значило либо осложнить жизнь добросовестным разработчикам, либо сделать всю систему реквизитов доступа почти бесполезной. Особенно если речь идет об Open Source.<br /> <br /> ;В<br /> <br /> :Фу! Разумеется, хорошего тут мало, но почему это так?<br /> <br /> ;О<br /> <br /> :Потому что схема, которую я описал, превосходно работает в том случае, если реквизиты прописаны в исходном коде и/или компилированной программе, работающей только на web-сервере, где нельзя прочитать эти реквизиты в самом коде, или же, посредством шестнадцатеричных редакторов и им подобных, в исполняемых файлах программы.<br /> <br /> ;В<br /> <br /> :Так вот почему с открытым ПО проблема еще больше?<br /> <br /> ;О<br /> <br /> :Именно. Если вы включаете что-то заведомо конфиденциальное в исходный код, который может скачать и изучить любой... оно уже не конфиденциально по определению, не так ли?<br /> <br /> ;В<br /> <br /> :Конечно, но тут речь идет только о меньшей эффективности существующей схемы. А почему вы упоминали, что OAuth «ломает» существующее ПО?<br /> <br /> ;О<br /> <br /> :Потому что до OAuth 1.0, любой человек, минимально знакомый с написанием скриптов оболочки и с URL (к таковым причисляется, между прочим, ваш покорный слуга!), мог за пару минут создать нечто, позволяющее автоматически зарегистрироваться в Twitter, прочитать ленту или создать пост. С появлением OAuth это стало невозможно без предоставления достоверных, зарегистрированных реквизитов доступа. Даже если получать эти реквизиты приходится дольше, чем писать скрипт!<br /> <br /> ;В<br /> <br /> :А нельзя ли как-то исправить эти скрипты?<br /> <br /> ;О<br /> <br /> :Конечно, можно: достаточно использовать всего одну из многочисленных библиотек ПО, которые уже зарегистрированы. Однако процесс написания и поддержки сценариев все равно останется более сложным, чем раньше. По крайней мере до выхода OAuth 2.0<br /> <br /> ;В<br /> <br /> :Ага, значит, ожидается версия 2.0? А когда?<br /> <br /> ;О<br /> <br /> :На данный момент, планируется, что OAuth 2.0 будет готов к концу 2011.<br /> <br /> ;В<br /> <br /> :Что нового в OAuth 2.0? Решит ли он эти проблемы?<br /> <br /> ;О<br /> <br /> :Возможно. Одним из главных изменений является добавление или переопределение так называемых «потоков» [flows] для ускорения получения реквизитов доступа, даже если клиент является не web-сервером, а, к примеру, приложением на мобильном устройстве. Предусмотрен также поток на основе cookies, позволяющий оживить старые скрипты, использующие cURL. Ожидается также и повышение производительности, поскольку OAuth 1.0 не очень хорошо масштабируется.<br /> <br /> ;В<br /> <br /> :Где можно получить дополнительную информацию?<br /> <br /> ;О<br /> <br /> :Официальное представление OAuth – на сайте http://OAuth.net/about/ или http://hueniverse.com/2010/05/introducing-OAuth-2-0/.</div>

2sash-kan