2

I'm using Fiddler to issue the following request to our OpenID Connect Identity Server.

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

The OpenID Connect Identity Server replies with this response. 

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 contains this information. 

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

We've used ClaimType.NameIdentifier as placeholder text for the time being. So, the request/response are successful, and the Identity Server provides the relying party with both an id_token and access_token.

Our questions is, how can our request be successful, when it doesn't fulfill the OpenID Connect authentication request requirements listed here. That is, we're doing a username password flow that doesn't seem to be covered by the spec.

I suspect that this just means that our implementation of the OpenID Connect Identity Provider is not complete. Is that right? What's going on here?

Shaun Luttin
  • 133,272
  • 81
  • 405
  • 467
  • 1
    FYI, the chapter you mentioned is about the "authentication/authorization request", not the token request. But yeah, @Hans is right, the ROPC grant is not defined by the OIDC specs and is directly inherited from OAuth2. I'm personally not a huge fan of this grant type for the exact reasons @Hans mentioned, but removing it from `AspNet.Security.OpenIdConnect.Server` was definitely not an option, as it's still a popular grant type, which has its own pros/cons and is objectively a great way to replace basic authentication. – Kévin Chalet Jun 27 '15 at 16:56
  • 1
    If you're looking for non-standard things in this project, there are actually a few ones. For instance, the OIDC discovery specs (https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata) explicitly declare the `authorization_endpoint` parameter of a provider metadata response as "required", but on the other hand, `OpenIdConnectServerMiddleware` allows you to disable it if you don't want to support the basic/standard OIDC flows (code, implicit and hybrid) and prefer using the OAuth2 grants like ROPC or Client Credentials. – Kévin Chalet Jun 27 '15 at 17:05
  • 1
    @Pinpoint Given that you aren't a fan of the ROPC grant, how would you implement the type of sign on that, for instance, StackOverflow uses? That is, they give the option of using either an external provider or using StackExchange. I'm assuming that they do an ROPC grant for using StackExchange. What's your sense? – Shaun Luttin Jun 27 '15 at 23:47
  • 1
    If you don't want to use the authorization code flow, the ROPC grant type might be a good option, but I'd only use it with fully trusted clients: typically, **a website that you own** and that can safely receive your users' credentials to send them to the OIDC provider. Using ROPC with client apps you don't own clearly defeats the whole purpose of OAuth2/OIDC, as explained by @Hans. I don't know how SO guys implemented their authentication system, but I guess that stackoverflow.com is a fully trusted web app registered with stackexchange.com, which makes ROPC a good candidate for that. – Kévin Chalet Jun 28 '15 at 13:40

1 Answers1

3

The implementation of your OpenID Connect Provider goes beyond what is explicitly specified in the OpenID Connect specifications. There's no explicit Resource Owner Password Credentials grant defined in OpenID Connect but implementations may inherit that grant from OAuth 2.0. If it were standardized in OpenID Connect it would surely require the scope with value openid in there as well as a client_id.

So this is a non-standard extension grant implementation of OpenID Connect. Though the implementation may still be complete if it supports the required elements of the core OpenID Connect specification.

Note that the Resource Owner Password Credentials grant defeats the point of a federated SSO protocol, namely that the Relying Party does not get to see or deal with the user credentials. That is why it is not standardized in OpenID Connect and is a part of OAuth 2.0 "for migration purposes" only.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • 1
    Given that the Resource Owner Password Credentials flow is not standardized in OpenID Connect, what is the recommendation for implementing a rudimentary RESTful authentication/authorization in a web app? I've seen sites, such as StackOverflow, offer both external providers and their own provider. For implementing their own provider, we don't have to leave their site. How do we do this within the OpenID Connect paradigm? The Login with Stack Exchange doesn't redirect the end user to another page, but Stack Exchange seems to be the Identity Provider using a ROPC flow and SO sees the credentials. – Shaun Luttin Jun 26 '15 at 18:42
  • 2
    An a) LDAP, a b) database call or c) HTTP basic auth returning a JSON object basically achieve all the same thing. Within OpenID Connect ROPC is the way to go, except for that it is not explicitly standardized which puts you in *nearly* the same boat as c). – Hans Z. Jun 26 '15 at 18:53
  • 1
    So, it sounds like despite it being non-standardized, using ROPC flow with OpenID Connect is an appropriate approach. Is that right? – Shaun Luttin Jun 26 '15 at 18:54
  • 2
    It is certainly as valid (if not a little more) as the alternatives. – Hans Z. Jun 26 '15 at 18:56