Inappropriate error code 'unsupported_grant_type' during authorization request

[cicnavi]

Hi, thank you for your wonderful work on oauth2-server package.

According to OAuth 2.0 spec for errors during authorization request, authorization server should return error 'unsupported_response_type' if the response_type parameter is invalid (missing, unsupported value...). The current implementation returns error code 'unsupported_grant_type', which is not in accordance to the spec.

The only place in spec where I see error code 'unsupported_grant_type' is in section 5. Issuing an Access Token.

So, as I understand it, the error code 'unsupported_response_type' should be related to the 'response_type' parameter which is used in authorization request. The error code 'unsupported_grant_type' should be related to the 'grant_type' type parameter which is used in token request.

Best regards

[Sephster]

Thanks @cicnavi - this is an interesting one. We don't specifically ever check for the response_type parameter in the way the oauth 2 spec expects. If a client sends in an authorization request, the server retrieves all enabled grant types, and checks against each one whether it can respond to an auth request.

public function validateAuthorizationRequest(ServerRequestInterface $request)
    {
        foreach ($this->enabledGrantTypes as $grantType) {
            if ($grantType->canRespondToAuthorizationRequest($request)) {
                return $grantType->validateAuthorizationRequest($request);
            }
        }

        throw OAuthServerException::unsupportedGrantType();
    }

In the case of the authcode grant, we check if a response_type has been set, if that is set to code, and if a client ID has been set. If any of these aren't satisfied, we assume the client didn't want to use this grant but they might have wanted to use another one...

If we can't find any grants that can run the type of auth request the client has sent, we return unsupported_grant_type.

I will need to look into it more but I think the challenge would be definitely knowing the client meant to use a particular grant as we don't have endpoints for each type.

[cicnavi]

Thank you Andrew for getting back to this! I'll just humbly comment on the implementation, with total respect on the current workings of the package and not expecting to change this anytime soon or at all. From the spec, I can see that the authorization code flow and implicit flow use authorization endpoint. Both flows use basically the same requests by the spec, and I can see the practically duplicated code in methods '$grantType->validateAuthorizationRequest($request)' in each grant, the difference being PKCE handling for public clients. Other flows like 'Resource Owner Password Credentials', 'Client Credentials', 'Refresh Token' only use token endpoint and their token requests are different (use different parameters so they require specific implementation). If I were to implement validation for the authorization requests, I would do it in one place since it is the same for all grants that use it (and would also handle PKCE for public clients). Also, I would do it in the following order so I can do the HTTP redirection of error responses as the spec mandates: * first validate client_id and redirect_uri. If any of those is not ok, throw error, that is show error to the resource owner (no HTTP redirection error) * do all other validations including checking for valid response_type. If any of that is not ok, return error using HTTP redirect and in that way inform the client itself about the error Best regards and again thank you for your great work!

…

-- Marko Ivančić https://markoivancic.from.hr

On Sun, May 16, 2021 at 12:59 AM Andrew Millington ***@***.***> wrote: Thanks @cicnavi <https://github.com/cicnavi> - this is an interesting one. We don't specifically ever check for the response_type parameter in the way the oauth 2 spec expects. If a client sends in an authorization request, the server retrieves all enabled grant types, and checks against each one whether it can respond to an auth request. public function validateAuthorizationRequest(ServerRequestInterface $request) { foreach ($this->enabledGrantTypes as $grantType) { if ($grantType->canRespondToAuthorizationRequest($request)) { return $grantType->validateAuthorizationRequest($request); } } throw OAuthServerException::unsupportedGrantType(); } ``` In the case of the authcode grant, we check if a response_type has been set, if that is set to code, and if a client ID has been set. If any of these aren't satisfied, we assume the client didn't want to use this grant _but_ they might have wanted to use another one... If we can't find any grants that can run the type of auth request the client has sent, we return unsupported_grant_type. I will need to look into it more but I think the challenge would be _definitely_ knowing the client meant to use a particular grant as we don't have endpoints for each type. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1216 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYHTDDO6KGBITO4UICJXTTTN34GRANCNFSM43HW5PJA> .