Протокол 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 заключается в том, что она требует, чтобы сервер и клиенты сортировали и подписывали одинаково. Это код fiddly, и либо это правильно, либо вы получаете 401 Unauthorized с небольшой помощью. Это увеличивает барьер для написания клиента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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