Test 18: Client Authentication (Authorization Code Flow) IIB3a tests

[Joseph Shook]

I am happy to say the .NET RI can now pass the happy path for authorization_code grant type flow.  

But I have issues with the test tools opinions on expected behavior when submitting invalid requests to GET /authorize? .  

Currently I fail all of those tests because they assume I will return an HTTP error code (400-599). 

Instead I return a 302 in the format of  home/error?errorId=CfDJ8Mt5lft...  

The Duende Identity Server internal code has a strong opinion on this behavior.  There is no standard abstraction to change this.  I could add middleware to change the response bavior after the Duende internal code runs.

But in the current behavior the user can see the reason for the error on the redirected page which looks up the errorId displaying the error and error_description to the user.

As I read the udap.org docs in section 3.1 Authorization Code Flow, it does not speak on how to respond to the client (user in this case).  RFC 6749 does speak to this.  For example in section 3.1.1 I says, 

" If an authorization request is missing the "response_type" parameter, or if the response type is not understood, the authorization server MUST return an error response as described in Section 4.1.2.1.  "

So you have to go to Section 4.1.2.1 to determine what this response should be.  

" 4.1.2.1. Error Response If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHOULD inform the resource owner of the error and MUST NOT automatically redirect the user-agent to the invalid redirection URI. "

In my RI the AS informs the resource owner of the error and does not automatically redirect the user-agent to the invalid redirection URI.  

From a testers perspective it would be tough to interpret this technique vs expected behavior today.  

Duende does have some times where it would respond to the client but it is always as a 302, and never a 400-599.

I guess I am asking you to consider a technique in addition to the current expectation, where the test tool interogates the redirected error Url.

The users experience looks like this.

Thoughts?

[Luis Maas]

Hi Joe,

The 4.1.2.1 flow exists to give control back to the app and to communicate the error information to the app (not to the user / resource owner). This redirection is used for authorize requests with a valid client id and valid redirect URI for the app. The app can then show the user the error and/or try another authorize request with different parameters. It is not enough for the server to show the resource owner the error, as in your screenshot, because then the app will not know what happened and the flow effectively stops.

But your message also mentions the tests where 400-599 is expected, i.e. where the server must not automatically redirect because the request doesn't have a valid client id and valid redirect URI for the app. The unsupported_response_type test from your screenshot is not one of those -- that one should have been redirected. A 400-599 test would be something like an authorize request with a missing client id. In those cases, the test tool should follow the redirect to home/error?errorId=... and any subsequent redirects until a non 3xx response is returned, and then base the test result on what is returned from that final page. Can you share the failure message the tool is giving you for these tests?

Luis

[Joseph Shook]

Nice.  I know it is Luis resonding today.  :)

Here is the report link and mistakenly left out previously.

I guess I did pick the missing response_type as my scenario while I mentioned the 400-599 expected response.  That makes my explanation a little confusing.  But in both the IIB3a1 and  IIB3a2 sub tests Duende's Identity Server defaults to a 302  home/error?errorId=... on the authorization server.  

I see IIB3a1 as being a precheck and would have expected Duende's Identity Server to respond like the subtest errors describe.  I am not sure why they default to an error page on the Auth Server.   

For IIB3a2.  It seems clear a response to the redirect URI with and error would be the expected behavior.   

To be honest I think the test tool is asserting what should happen.  I was hoping you would say, "Oh, there is this other behavior that could be interpreted as correct” and then you would proceed to tell me where I could read more about it.  For a code base (Duende) that is mature I expected more consistencies with other implementations.  If you have more knowledge to shed light on this that would be great.  But I will have to present these questions to them.  I know how I will resolve this technically but always on the hunt for a longer-term architecture solution that isn't about patching a behavior.