Может ли OAuth 2.0 поддерживать несколько грантов в одном пути перенаправления?

Question

Мой вопрос довольно прост:

Если у вас есть два компонента веб-приложения:

1. Серверный (с поддержкой секретов) код на PHP, Python, Perl ..* независимо
2. Вывод JavaScript и интерпретация браузером

При одном перенаправлении на конечную точку авторизации (и обратно) можно указать и передать информацию для:

1. Предоставление кода авторизации (для кода на стороне сервера)
2. Неявное предоставление с ограниченными правами для Javascript

, тем самым передавая два разрешения (однов собственном URL-адресе запроса, а другой во фрагменте) за один цикл, не нарушая RFC?

Один цикл перенаправления кажется чище, чем один для каждого гранта (даже если второй не блокируется из-задо предыдущей авторизации)

Заранее спасибо!

Ссылки

1. http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.2

изменить 1: code_and_token похоже на то, чем я являюсьпосле ... предоставление кода авторизации серверу для запроса кода доступа с использованием его учетных данных ... и неявный токен для JavaScript.Как упоминает mov matake, он был извлечен из RFC после v11, но никаких реальных объяснений почему не было.Кажется, Facebook и Google поддерживают это, что заставляет меня подозревать, что оно вернется.

Answer 1

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

Он не будет добавлен в спецификацию, но может быть легко введен расширением. Google поддержал этот поток в списке, но позже сказал, что не будет реализовывать его, а вместо этого будет реализовывать что-то еще, используя функции HTML5.

Answer 2

OAuth 2.0 ранее имел тип ответа "code_and_token" (может быть "token_and_code").Но он был удален из спецификации позже.

Так что в текущей спецификации, если вам нужен код для вашего сервера, путь будет

• , используйте тип ответа "code"
• получите токен доступа на стороне сервера
• и передайте его клиентской стороне

Вы не можете получить токен с ограничением области действия только для клиентской стороны .. ИлиВы можете настроить прокси на своем сервере для своего клиентского кода.

Answer 3

http://www.ietf.org/mail-archive/web/oauth/current/msg04969.html и http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html

говорит, что тип "code_and_token" был хорош, но RFC не прояснил достаточно, чтобы токен во фрагменте (для Javascript) имел / мог иметь меньше прав, чем токен, полученный кодом доступа ...

Спасибо Nov Matake за указание на то, что тип code_and_token был частью спецификации (в какой-то момент), поскольку я пропустил ее в старых версиях спецификации (хотя она широко реализована).

Похоже, что он вернется, поскольку он довольно хорошо поддерживается существующими реализациями в Google и Facebook и, похоже, является основным запросом для поддержки как токенов пользовательского агента, так и доступа на стороне сервера. коды в одну поездку.

Проблема, по-видимому, заключается в определении семантики «области действия» в этом контексте, а также в определении степени, в которой область действия может отличаться в одном запросе. Имеет смысл, что токен агента пользователя имеет ограниченные права, т.е. не совпадает с правами клиентского приложения.

Мы подождем и увидим ... обратную сторону реализации с привлечением RFC.