В чем преимущество OAuth2 неявного предоставления по сравнению с предоставлением кода авторизации

Question

В чем преимущество OAuth2 в неявном предоставлении по сравнению с предоставлением кода авторизации?

В частности, мне интересно, почему неявное предоставление рекомендуется для общедоступных клиентов, а предоставление кода авторизации - нет.Они кажутся настолько похожими, что разница не важна.

Answer 1

Преимущества шага кода авторизации заключаются в следующем (от OAuth 2.0 spec 1.3.1 ):

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

Обычно, если ваш клиент находится на стороне сервера (веб-приложение), вы должны использовать код авторизации. Если это приложение на основе JavaScript (на стороне клиента) - неявное уместно Для мобильных приложений предпочтительным является тип предоставления кода авторизации, если используется внешний браузер (не встроенный).

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

Answer 2

Сравните действия клиента в обоих случаях, учитывая, что клиент - это часть программного обеспечения, которую вам придется написать самостоятельно.

В случае Authorization code grant клиент выполняет те шаги, которые определены в спецификации:

1. Клиент запрашивает токен доступа с токена сервера авторизации конечная точка, включая код авторизации, полученный на предыдущем шаге. когда делая запрос, клиент аутентифицируется на сервере авторизации. клиент включает в себя URI перенаправления, используемый для получения кода авторизации для проверка.
2. Сервер авторизации аутентифицирует клиента, проверяет код авторизации, и гарантирует, что полученный URI перенаправления совпадает с URI, использованным для перенаправления клиент на шаге (с). Если допустимо, сервер авторизации отвечает обратно с доступом токен и, необязательно, токен обновления.

В случае Implicit Grant это должно сделать:

1. Получить токен доступа.

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