Наш запрос OpenID Connect успешно выполняется, хотя ему не хватает требуемых параметров.

Я использую Fiddler для запроса следующего.Наш запрос OpenID Connect успешно выполняется, хотя ему не хватает требуемых параметров.

POST http://localhost:50000/connect/token HTTP/1.1 
User-Agent: Fiddler 
Host: localhost:50000 
Content-Length: 73 
Content-Type: application/x-www-form-urlencoded 

grant_type=password&username=my_username&password=my_password&nonce=12345

Ответ сервера идентификации OpenID отвечает этим ответом.

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Length: 2136 
Content-Type: application/json;charset=UTF-8 
Expires: -1 
Server: Microsoft-IIS/10.0 
X-SourceFiles: =?UTF-8?B?QzpcVXNlcnNcQmlnRm9udFxEb2N1bWVudHNcR2l0SHViXEFzcE5ldC5TZWN1cml0eS5PcGVuSWRDb25uZWN0LlNlcnZlclxzYW1wbGVzXFJlc291cmNlT3duZXJQYXNzd29yZEZsb3dcd3d3cm9vdFxjb25uZWN0XHRva2Vu?= 
X-Powered-By: ASP.NET 
Date: Fri, 26 Jun 2015 17:49:39 GMT 

{"token_type":"bearer","access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjA1MkM1RTQyMTVDRDBDMUUxNTA1RTA4RTZBRjNBREJFRkJGRDc4MjIifQ.eyJuYW1laWQiOiJDbGFpbVR5cGVzLk5hbWVJZGVudGlmaWVyIiwidW5pcXVlX25hbWUiOiJKb2huIiwiZmFtaWx5X25hbWUiOiJEb2UiLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjUwMDAwLyIsImV4cCI6MTQzNTM0NDU3OSwibmJmIjoxNDM1MzQwOTc5fQ.Yp79C1xpfDb21iR0O7pkuQIrSp539Qf8zWlZGAZveYEs7IEiE9vepK39mMFM5UpVPSgxwtEeig4O1eHSDDJayQEXN1Q1nOqWJtww6I8mlBGmx0YQSQLmV3saTKEhs6Y4VNBe5A9X9xiWURkZhrTRS_SxkztibYZ8XlkcVUQ6OZeDx9OVdXpYl8R3B6deymBDDADWichKrkDhb4lhpOFrUrmloBR-A4Zya4luh2h33_3D3XgtJf9mtGvmrisTWPK2JLbpVkRIOMZQ2j_F7Azo1rl0UXaQ5OIe2M3iR7QyHCz92_YvwT-0gMkSv4uf-_CO5xj1gy8GwpJi0_4oG7BXaA","id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjA1MkM1RTQyMTVDRDBDMUUxNTA1RTA4RTZBRjNBREJFRkJGRDc4MjIifQ.eyJuYW1laWQiOiJDbGFpbVR5cGVzLk5hbWVJZGVudGlmaWVyIiwidW5pcXVlX25hbWUiOiJKb2huIiwiZmFtaWx5X25hbWUiOiJEb2UiLCJpYXQiOiIxNDM1MzQwOTc5IiwiYXRfaGFzaCI6InBvRG12TVcwbWN6clhMY3RLNUNkd1EiLCJub25jZSI6IjEyMzQ1Iiwic3ViIjoiQ2xhaW1UeXBlcy5OYW1lSWRlbnRpZmllciIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6NTAwMDAvIiwiZXhwIjoxNDM1MzQyMTc5LCJuYmYiOjE0MzUzNDA5Nzl9.kFo9AcB0mB-ol9PtelRkqh0hW34iYPxnHV0kOeRztdngffsV7rK5xwZqhWVRr_UHKaE-368BCmRgxNGApNeAaCzgYqGoXlDWI-9pd4xfpnohuWW7I83dupArk8xPdTBU_ulHAYwIRWzQilCt9vwEtHLBDLdaS_DkuTAR-fEl95ARC7xoBvpsiQAZs2Tk03s0TJVU0mp9FPv7igxOjyyyRPuCZyXO8FQE-AobsNMjPjrXILfwttpsJYXr8A-HyZtxtLkNl_lHhIcCxWmSvIFrMq7qRRKHh_nQWHHuL1PGGeHiNpsfXA7AsU1XjIx4Q6q6dYWBRT_tKm8b_NjkYAIDDQ","refresh_token":"CfDJ8FNfFcvZnUZCl--dx0lsB1d2NUScvcEhi5sOoCFE4aNgAUHW8ieHtSuA0d13DtiYnpVoO03v5eRRMvyUAVWN9X51544obo4kd5XQJX6bLD3XnPlPs8Fn0n1e-b1RVlQ8NW56bHrJDcSTxiGgzikwAOdmBlCc7K6-NCttTjK_ktQEd_sFsAS77Wb8t5g-bZWMJRWuSnQPFhrUyw3HoFXiP2qkFLTRU6alOud9usRB3Tq_UtxVsVanBtqCmsW07puKqiTuOjBhau0jX9GlWfHa1ZsvncgsaHS3FIoHGPaRXyYqABtIUbPUWfRJRoL0OihSm0wLLZPrYSwNVMWRp8Wb6ClOxZtaWxpJmF7BaTDyu3BOjDf-AUIDTVHDDPYtA8SUlWXlPXm6ekeOzGHCA9J8Ri-TRxaAW_LWdn1C2H44W6TLCxGEzsLn53M8IAnMqAEGr6eTCxN6jaffsKhXVlqbtXnSjg9nYsxvKHOPQmmiIRFGpuohoPzNHbxxaurFEabAMLegi21xVTi15RoGs-xtfrnl7x8WH834IlYh6E-D_8rLP0zg81HO8QoKqnEtFZlTfNrZsdGx7lka5IO9MRtiPyVtWQNZN9fJPCASRYngEtQV","expires_in":"3599"}

The id_token содержит эту информацию.

{ 
nameid: "ClaimTypes.NameIdentifier", 
iat: "1435340979", 
at_hash: "poDmvMW0mczrXLctK5CdwQ", 
nonce: "12345", 
sub: "ClaimTypes.NameIdentifier", 
iss: "http://localhost:50000/", 
exp: 1435342179, 
nbf: 1435340979 
}

Мы использовали ClaimType.NameIdentifier, как текст-заполнитель до поры до времени. Таким образом, запрос/ответ успешны, а Identity Server предоставляет полагающейся стороне как id_token, так и access_token.

Наши вопросы: как наш запрос может быть успешным, если он не соответствует OpenID Connect authentication request requirements listed here. То есть, мы делаем поток паролей имени пользователя, который, похоже, не покрывается спецификацией.

Я подозреваю, что это означает, что наша реализация OpenID Connect Identity Provider не завершена. Это правильно? Что тут происходит?

источник

2015-06-26 Shaun Luttin

FYI, упомянутая глава относится к запросу «аутентификация/авторизация», а не к токенному запросу. Но да, @Hans прав, грант ROPC не определяется спецификациями OIDC и прямо унаследован от OAuth2. Я лично не большой поклонник этого типа гранта для точных причин, упомянутых в @Aans, но удаление его из «AspNet.Security.OpenIdConnect.Server» было определенно не вариантом, поскольку он по-прежнему является популярным типом гранта, который имеет собственные плюсы/минусы и объективно - отличный способ заменить базовую аутентификацию. – Pinpoint

Если вы ищете нестандартные вещи в этом проекте, их действительно несколько. Например, спецификации обнаружения OIDC (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata) явно объявляют параметр 'authorization_endpoint' ответа метаданных поставщика как« обязательный », но на с другой стороны, «OpenIdConnectServerMiddleware» позволяет отключить его, если вы не хотите поддерживать базовые/стандартные потоки OIDC (код, неявный и гибридный) и предпочитаете использовать гранты OAuth2, такие как ROPC или Client Credentials. – Pinpoint

@Pinpoint Учитывая, что вы не являетесь поклонником гранта ROPC, как бы вы реализовали тип знака, например StackOverflow? То есть они дают возможность использовать внешний поставщик или использовать StackExchange. Я предполагаю, что они предоставляют грант ROPC для использования StackExchange. В чем ваш смысл? –

Реализация вашего провайдера соединений OpenID выходит за рамки того, что явно указано в спецификациях OpenID Connect. В OpenID Connect нет явного мандата учетных данных владельца ресурса, но реализации могут наследовать этот грант от OAuth 2.0. Если бы он был стандартизован в OpenID Connect, он, несомненно, потребовал бы scope со значением openid, а также client_id.

Так что это нестандартная реализация гранта расширения OpenID Connect. Хотя реализация может быть завершена, если она поддерживает требуемые элементы базовой спецификации OpenID Connect.

Обратите внимание, что грант учетных данных владельца ресурса поражает точку единого протокола единого входа, а именно, что Сторона-оппонент не видит или не имеет доступа к учетным данным пользователя. Вот почему он не стандартизован в OpenID Connect и является частью OAuth 2.0 «только для целей миграции».

источник

2015-06-26 18:37:41

Учитывая, что поток учетных данных для владельца ресурса не стандартизован в OpenID Connect, какова рекомендация по внедрению элементарной аутентификации/авторизации RESTful в веб-приложении? Я видел сайты, такие как StackOverflow, предлагающие как внешние поставщики, так и их собственный провайдер. Для реализации своего собственного провайдера нам не нужно оставлять свой сайт. Как мы это делаем в рамках парадигмы OpenID Connect? Вход с помощью Stack Exchange не перенаправляет конечного пользователя на другую страницу, но Stack Exchange, по-видимому, является поставщиком удостоверений с использованием потока ROPC, а SO видит учетные данные. –

a) LDAP, b) вызов базы данных или c) HTTP basic auth, возвращающий объект JSON, в основном реализует все то же самое. В OpenID Connect ROPC - это путь, за исключением того, что он явно не стандартизирован, что ставит вас в * почти * ту же лодку, что и c). –

Итак, похоже, что несмотря на то, что он нестандартизирован, использование ROPC-потока с OpenID Connect является подходящим подходом. Это правильно? –

Наш запрос OpenID Connect успешно выполняется, хотя ему не хватает требуемых параметров.

ответ

Смежные вопросы