Протокол OAuth 2.0: преимущества и варианты - почему?

фон: я написал клиентские и серверные стеки для OAuth 1.0 a и 2.0.

оба протокола OAuth 1.0 и 2.0 Поддержка двуногая аутентификация, где сервер уверен в идентичности пользователя, и трехногая проверки подлинности, где сервер гарантирован поставщиком контента идентичности пользователя. Трехногая аутентификация-это то, где запросы на авторизацию и маркеры доступа вступают в игру, и важно отметить, что OAuth 1 имеет их, тоже.

комплекс один: трехногая аутентификация

основной пункт спецификаций OAuth предназначен для контент-провайдер (например, Facebook, Twitter и др.) для обеспечения сервер (например, веб-приложение, которое хочет поговорить с поставщиком контента от имени клиента), что клиент имеет некоторую идентичность. То, что предлагает трехногая аутентификация, - это возможность сделать это без клиента или сервера не нужно знать детали этого идентичность (например, имя пользователя и пароль).

без (?) слишком углубляясь в детали OAuth:

1. клиент отправляет запрос авторизации на сервер, который проверяет, что клиент является законным клиентом своей службы.
2. сервер перенаправляет клиента к поставщику контента для запроса доступа к его ресурсам.
3. поставщик контента проверяет личность пользователя и часто запрашивает его разрешение доступ к ресурсу.
4. поставщик контента перенаправляет клиента обратно на сервер, уведомляя его об успехе или неудаче. Этот запрос включает код авторизации при успешном выполнении.
5. сервер делает внеполосный запрос к поставщику контента и обменивает код авторизации на маркер доступа.

теперь сервер может делать запросы к поставщику контента от имени пользователя, передавая маркер доступа.

каждый exchange (client->server, server->content provider) включает проверку общего секрета, но поскольку OAuth 1 может работать через незашифрованное соединение, каждая проверка не может передать секрет по проводу.

это сделано, как вы заметили, с HMAC. Клиент использует секрет, которым он делится с сервером, чтобы подписать аргументы для своего запроса на авторизацию. Сервер принимает аргументы, подписывает их сам ключом клиента и может видеть, является ли это законным клиентом (в Шаг 1 выше).

эта подпись требует, чтобы клиент и сервер согласовали порядок аргументов (поэтому они подписывают точно такую же строку), и одна из основных жалоб на OAuth 1 заключается в том, что он требует, чтобы сервер и клиенты сортировали и подписывали одинаково. Это верный код, и либо это правильно, либо вы получите 401 Unauthorized с небольшой помощью. Это увеличивает барьер для написания клиента.

, требуя, чтобы запросить разрешение работать по протоколу SSL, OAuth 2.0 полностью устраняет необходимость в сортировке и подписывании аргументов. Клиент передает свой секрет на сервер, который проверяет его напрямую.

те же требования присутствуют в соединении server->content provider, и поскольку это SSL, который удаляет один барьер для записи сервера, который обращается к службам OAuth.

что делает вещи намного проще в шагах 1, 2 и 5 выше.

таким образом, на данный момент наш сервер имеет постоянный токен доступа, который является имя пользователя/пароль эквивалентны для пользователя. Он может делать запросы к поставщику контента от имени пользователя, передавая этот маркер доступа как часть запроса (в качестве аргумента запроса, заголовка HTTP или данных формы POST).

если доступ к контенту осуществляется только через SSL, мы закончили. Если он доступен через простой HTTP, мы хотели бы каким-то образом защитить этот постоянный токен доступа. Любой, кто нюхает соединение, сможет получить доступ к контенту пользователя навсегда.

способ, который решается в OAuth 2, - это с маркер. Токен обновления становится эквивалентом постоянного пароля, и это только когда-либо передавалось по SSL. Когда серверу требуется доступ к службе содержимого, он обменивает маркер обновления на маркер кратковременного доступа. Таким образом, все нюхательные HTTP-обращения выполняются с токеном, срок действия которого истекает. Google использует 5-минутный срок действия на своих API OAuth 2.

Так помимо токенов обновления, OAuth 2 упрощает все коммуникации между клиентом, сервером и поставщиком контента. И токены обновления существуют только для обеспечения безопасности при доступе к содержимому в незашифрованном виде.

двуногая аутентификация

Иногда, однако, сервер просто должен контролировать доступ к своему собственному контенту. Двуногая аутентификация позволяет клиенту аутентифицировать пользователя непосредственно на сервере.

OAuth 2 стандартизирует некоторые расширения для OAuth 1, которые широко использовались. Тот, кого я знаю лучше всего, был представлен Twitter как xAuth. Вы можете увидеть его в OAuth 2 как Пароль Владельца Ресурса Учетные Данные.

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

С OAuth 1 это не было частью официального стандарта и требовало такой же процедуры подписания, как и все другие запросы.

Я только что реализовал серверную часть OAuth 2 с учетными данными пароля владельца ресурса, и с точки зрения клиента получение маркера доступа стало простым: запросите маркер доступа с сервера, передав идентификатор/секрет клиента в качестве авторизации HTTP заголовок и логин/пароль пользователя в виде данных формы.

Преимущество: Простота

таким образом, с точки зрения разработчика, основные преимущества, которые я вижу в OAuth 2, заключаются в уменьшении сложности. Это не требует процедуры подписания запроса, что не совсем сложно, но, безусловно, неудобно. Это значительно сокращает работу, необходимую для того, чтобы выступать в качестве клиента сервиса, где (в современном, мобильном мире) вы больше всего хотите минимизировать боль. Уменьшенная сложность на сервер- > content provider end делает его более масштабируемым в центре обработки данных.

и он кодирует в стандарт некоторые расширения для OAuth 1.0 a (например, xAuth), которые теперь широко используются.