Our OpenID Connect request succeeds though it lacks required parameters

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?

Solution

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.