В 101 раз про OAuth

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

Да, про авторизацию в различных сервисах я уже писал неоднократно и по-разному — кратко, подробно, подробно и с картинками, но, как показывает мой скромный опыт работы с самыми разными онлайн-сервисами, практически каждый сервис, поддерживающий авторизацию по протоколу OAuth привносит в процесс авторизации свои коррективы. Конечно, эти коррективы не столь значительны, чтобы пришлось каждый раз писать новый компонент для авторизации (тот же компонент для авторизации из REST Client Library в 99% работает безукоризненно как в VCL так и в FMX), но тем не менее, знать как использовать OAuth в самых различных ситуациях всё же стоит. Более того, стоит и понимать те риски, которые будут возникать в том случае, если вы решите, что OAuth — это не для вас.

Именно так: жирным шрифтом и на краном фоне. Объясню, почему я обращаю на это внимание. Дело в том, что уже неоднократно как в блоге, так и в скайпе/твиттере/фейсбуке мне задавали вопрос — как избавиться от браузера при авторизации по OAuth. Дескать, напрягает он и вообще ломает всю красоту и изящность приложения и без него было бы намного лучше.

Избавиться от браузера при авторизации по протоколу OAuth вы можете только в одном случае — когда запрашиваете в своем приложении у пользователя логин и пароль от аккаунта, потом долго и упорно изучаете все «движения» данных по сети — куда сервер перенаправляет, какие куки устанавливает, что просит и очередном запросе т.д. А потом начинаете парсить html код странички онлайн-сервиса на которую, по-хорошему, пользователь обязан зайти для ввода логина и пароля.

А теперь, посмотрим на суть протокола OAuth, например, прочитав вот эту статью в Википедии:

OAuth — открытый протокол авторизации, который позволяет предоставить третьей стороне ограниченный доступ к защищенным ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль.

Запросив логин и пароль от аккаунта у пользователя вы получаете следующие крайне сомнительные плюсы:

1. Пользователь для авторизации в сервисе делает ровно на один шаг меньше (он не жмет кнопку «Подтвердить доступ» в браузере).
2. В приложении будет на одну форму и несколько компонентов меньше и приложении станет «тоньше»

Вместе с этим вы получаете вполне очевидные проблемы:

1. Необходимо самому заботится о сохранности учётных данных пользователя. Врядли мне бы пришлось по душе то, что приложение хранит мои пароли в ini-файле рядам с exe.
2. Пользователю придётся доверять вам на слово, что вы «добрый и пушистый» и используете его учётные данные ровно для того, для чего просите. Дело в том, что при правильном подходе к авторизации (т.е. при использовании браузера) пользователь 100% видит, что ваше приложение хочет получать, например, доступ к альбомам в ВК или доступ на чтение/запись задач в Google и т.д. И пользователь САМ решает — устраивает его такие запросы от приложения или нет. В случае же «заботы о спокойствии пользователя» и избавлении от браузера пользователь вообще не видит, что вы будете делать с его аккаунтом. И могу вас уверить, что далеко не всем потенциальным пользователям вашего приложения такая ситуация понравится.
3. Необходимость парсинга HTML.  Да, сам процесс парсинга странички не вызывает особых затруднений, но вот в чем проблема — изменится дизайн страницы и придётся всё начинать сначала.
4. Вы теряете потенциальных пользователей. Еще раз подчеркну — вы никогда и ни при каких обстоятельствах не сможете доказать совершенно незнакомому человеку, что вы просите у него логин и пароль сугубо для работы приложения. Один поверит, 10 поверят, но, если вы пишете приложение с прицелом на большую аудиторию, то будьте готовы, что 101 пользователь поднимет в Сети «волну» по поводу того, что ваше приложение сильно много хочет.

В общем, если вы решились избавиться от браузера при авторизации по OAuth, то вы не только сводите на нет всю суть протокола, но и получаете в нагрузку лишний проблемы как в настоящем, так и в будущем. Подумайте на этим. Кроме того, на сегодняшний день в большинстве онлайн-сервисов используется протокол OAuth 2.0, который очень сильно упрощает как сам процесс авторизации, так и работу с API вообще.

Дело в том, что, как я сказал выше, OAuth 2.0  значительно упрощает процесс авторизации. Так, например, параметр Response-Type позволяет вам указать серверу, что выдавать в ответе — сразу токен доступа к API или же код подтверждения, который впоследствии вы меняете на токен. Только ради этого параметра стОит всё-таки уделить 5 минут времени на то, чтобы просмотреть не только пример кода авторизации, но и прочитать внимательно часть документации, касающуюся авторизации в сервисе вообще. Не все сервисы поддерживают Response-Type, но многие. Если же, Response-Type не поддерживается, внимательно читайте часть документации в которой говориться о процессе предоставления кода подтверждения — большинство серисов дублирует код подтверждения в Titke возвращаемой страницы в браузере или же в URL. Сможете автоматически извлечь код доступа из браузера и передать его на сервер — пользователи скажут вам только спасибо, тем более, что это действие никак не противоречит сути OAuth. Кроме того, прочитав документацию к API вы можете избежать использования повторных авторизаций пользователя (если это позволяет сделать сервис).

Приведу простой пример вышесказанного. В качестве подопытного сервиса возьмем ВКонтакте. Про авторизацию я рассказывал подробно тут.

Во-первых, сервис поддерживает использование Response-Type со значением token и, как следствие, ваши пользователи никгогда не увидят страничку в браузере которая будет выводит фразу:

Которая в некоторых случаях может появляться. В основном, когда разработчик ленится проверить URL страницы, получить из неё значение параметра code, и автоматически закрыть окно с браузером, что в Delphi делается элементарно.

Во-вторых, если вы авторизовались в ВК и получили ключ доступа, то следуя правилам ВК, через некоторое время срок действия токена кончится и вам придётся попросить пользователя пройти авторизацию ещё раз (правда уже по-проще — логин и пароль могут не потребоваться). Но это только в том случае, если вы не прочитаете документацию к API. А документация к API ВКонтакте в части описания прав доступа к API говорит следующее:

значение offline — доступ к API в любое время со стороннего сервера (при использовании этой опции параметр expires_in, возвращаемый вместе с access_token, содержит 0 — токен бессрочный).

Т.е. просим пользователя авторизоваться один раз и на всю жизнь, пока он сам не решит отключить ваше приложение, зайдя на специальную страничку в сервисе.

Так что по поводу второго пункта можно предложить перед началом написания кода выполнить следующее:

1. Найдите в документации информацию о том какую версию протокола OAuth поддерживает сервис
2. Если используется OAuth 2.0 — найдите информацию о том, какие способы авторизации поддерживаются (можно ли использовать параметр response-type=token)
3. Если для standalone-приложения в обязательном порядке сервис требует получать код подтверждения, то смотрите как этот код передается пользователю (только в коде страницы, в коде и в title, в коде и URL и т.д.). Если код можно получить в title или url, то автоматизируйте процесс отправки кода на сервер — не поленитесь и напишите пару строк кода, которые буду парсить код подтверждения, например из url и передавать его на сервер. Если код возвращается только в видимой части страницы (в html-коде, что в настоящее время практически не встречается), то не стОит писать парсер для его получения — пусть лучше пользователь скопирует его сам, чем через пару месяцев скажет, что ваше приложение перестало работать.
4. Внимательнейшим образом изучите информацию о том, какие права доступа может запросить приложение. Если есть возможность получить бессрочный токен — дайте пользователю возможность запросить такой токен. Не всегда пользователям по душе оказывается получение бессрочного токена (особо щепетильные могут и не дать доступ), но в абсолютном большинстве случаев — такой подход пользователям нравится.
5. Ищите информацию про обновление токена. Большинство сервисов позволяет вам автоматически менять устаревший токен доступа на новый без дополнительных действий со стороны пользователя. Для этого сервер вам выдает refresh_token, а от вас требуется всего лишь написание одного дополнительного метода в 10-15 строк кода.

Этот пункт, также как и предыдущий, напрямую связан с документацией. Как я говорил в самом начале статьи, сервисы могут привносить в процесс авторизации свои небольшие коррективы. И зачастую, эти коррективы связаны с развитием технологий. Сегодня многие сервисы заботятся о том, чтобы пользователю было удобно работать со страницей ввода логина/пароля вне зависимости от того на каком устройстве запускается приложение. Так, например, Яндекс при работе с OAuth позволяет передать на сервер дополнительный параметр display=popup, который «скажет» серверу, что пользователю необходимо передать страничку с облегченной версткой, которую удобно использовать для отображения на мелких экранах (например, на телефоне или планшете).

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

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

Книжная полка

	Автор: Дмитрий Осипов Название: Delphi. Программирование для Windows, OS X, iOS и Android Описание Подробно рассматривается библиотека FM, позволяющая создавать полнофункциональное программное обеспечение для операционных систем Windows и OS X, а также для смартфонов и планшетных компьютеров, работающих под управлением Android и iOS
	Автор: Андрей Шкрыль Название: Разработка клиент-серверных приложений в Delphi Описание: Рассмотрены практические вопросы по разработке клиент-серверных приложений в среде Delphi 7 и Delphi 2005 с использованием СУБД MS SQL Server 2000, InterBase и Firebird. Приведена информация о теории построения реляционных баз данных и языке SQL. Освещены вопросы эксплуатации и администрирования СУБД.
	Автор: Антон Григорьев Название: О чем не пишут в книгах по Delphi Описание: Рассмотрены малоосвещенные вопросы программирования в Delphi. Описаны методы интеграции VCL и API. Показаны внутренние механизмы VCL и приведены примеры вмешательства в эти механизмы. Рассмотрено использование сокетов в Delphi: различные режимы их работы, особенности для протоколов TCP и UDP и др.