DotNetOpenAuth - Как клиент аутентифицирует идентификатор и секрет?

Question

Я просто заканчиваю авторизацию и сервер ресурсов для OAuth2, используя DotNetOpenAuth 4.3.4. Для тестирования я создал тестовый клиент, выполнив OAuth2Client.

Поскольку я использую DNOA для всех сеансов связи и запроса, я не уверен, полностью ли я понимаю, что происходит под капотом. Но это знание очень важно, когда я делаю документацию.

Итак, не могли бы вы объяснить мне, как работает аутентификация клиента в DNOA? Я использую код авторизации как grant_type, и когда я использую свой тестовый клиент для обмена кодом для access_token, DNOA каким-то образом проверяет client_secret и client_id. Я загрузил исходный код для DNOA, но это не помогло.

Когда я установил точку останова на контроллер Oauth2 (метод токена) и проанализировал запрос как HttpRequestMessage, я вижу, что запрос содержит «grant_type», «code» и «redirect_uri». Но где client_id и client_secret?

Кроме того, можете ли вы сказать мне, где я могу найти любую полезную документацию для DNOA? Мне нужно создать документацию, которая будет действительной и пригодной для всех платформ, а не только C#, которая может использовать DNOA.

Связанный вопрос: Я где-то читал, что мы не должны создавать коды авторизации для unauthentificated клиентов, но это именно то, что делает DNOA (так как я получаю код авторизации, даже если секрет не так). Это нормально?

Edit:

Это запрос, который я пытаюсь читать. Это токеновый запрос клиента DNOA. Я не вижу client_id и client_secret по другим параметрам, таким как «код», «redirect_uri» и «grant_type». Мне трудно быть вместе. Может быть, мне не хватает чего-то важного из http-запросов и ответов.

Когда я даю DNOA HandleTokenRequest (запрос) продолжить, он успешно аутентифицирует клиентское приложение (не выполняется, когда в конфигурационном файле клиента DNOA установлен плохой секрет).

Edit 2

private readonly WebServerClient Client;  
protected override string QueryAccessToken(Uri returnUrl, string authorizationCode) 
      { 
       var authorization = Client.ProcessUserAuthorization(); 
       if (authorization != null) 
        return authorization.AccessToken; 
       else 
        return null; 
      } 

Это моя реализация QueryAccessToken. Это из какой-то выборки. Я думаю, что я создал это в начале и не менял его, потому что он работал.

Идти грубого источника DNOA Я узнал, что это метод от OAuth 1. Это может быть проблемой. Но вопрос в том, почему он работает нормально с правильными клиентскими экспертами и не работает с плохими.

Final редактировать

Похоже DNOA клиент использует HTTP Basic Authorization (client_id и секрет находятся в заголовке). Но мне нужен сервер DNOA, чтобы иметь возможность захватить эти параметры из POST.

Если кто-нибудь знает, как установить DNOA для поддержки client_id и client_secret в параметрах POST, это было бы потрясающе!

Спасибо

Answer 1

Предоставление разрешения на авторизацию требует двух шагов.

Первым шагом является переадресация браузера поставщику идентификационных данных и отображение входа ui. Код авторизации возвращается браузеру провайдером идентификации, а затем из браузера в клиентское приложение. Этот шаг не связан с секретом клиента! Это связано с тем, что конечный пользователь может отлаживать эту часть потока, и она не должна изучать ценность секретности клиента.

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

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

Также обратите внимание, что поток предоставления авторизационного кода является самым сложным, поскольку он включает как имя пользователя/пароль (предоставляется конечным пользователем), так и клиентский/клиентский секрет (предоставляется клиентским приложением). Есть другие потоки, которые позволяют получить токен авторизации в несколько иначе, а именно:

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

• поток учетных данных клиента, который включает в себя отправку клиентского/клиентского ключа посредством клиентское приложение к провайдеру idntity. Нет конечного пользователя, но только клиентское приложение, прошедшее проверку подлинности в поставщике удостоверений.

Больше о потоках здесь:

http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified

Что касается DNOA, я нашел, что это чистой и понятной, но документы отсутствуют. К счастью, примеры велики и хотя едва документированы, вы можете найти почти все. Тем не менее, я смог настроить oauth2 провайдер и сервер ресурсов через три дня и поддерживать все четыре потока oauth2. Я не буду подробно разбираться в деталях, поскольку это не то, о чем вы говорите, однако, если у вас есть конкретные вопросы DNOA, просто спросите.

Edit:: относительно вашего QueryAccessToken реализации, кажется, что вы используете WebServerClient внутренне. В моем коде я просто инициализировать его свойство:

WebServerClient client = ... 

client.ClientIdentifier = "client_id"; 
client.ClientCredentialApplicator = 
    ClientCredentialApplicator.PostParameter("client_secret"); 

С этими двумя сконфигурированных, как client_id и client_secret направляюсь к службе маркеров с client_secret передается в Params POST.