OAuth2\Extensions\OpenID\Endpoints\AuthorizationEndpoint::handleRequest()

Complexity

Conditions	4
Paths	18

Size

Total Lines	99
Code Lines	11

Duplication

Lines	0
Ratio	0 %

Importance

Changes

0

<?php
    function handleRequest(ServerRequestInterface $request): ResponseInterface

It is generally recommended to explicitly declare the visibility for methods.

    {
        $requestData = $request->getMethod() == 'GET' ? $request->getQueryParams() : $request->getParsedBody();


        try {
            /**
             * The Authorization Server MUST validate all the OAuth 2.0 parameters according to the OAuth 2.0 specification
             */
            $this->verifyRequestData($requestData);

It seems like $requestData can also be of type object and null; however, parameter $requestData of OAuth2\Extensions\OpenID\Endpoints\AuthorizationEndpoint::verifyRequestData() does only seem to accept array, maybe add an additional type check?

            /**
             * Verify that a scope parameter is present and contains the openid scope value.
             * (If no openid scope value is present, the request may still be a valid OAuth 2.0 request, but is not an OpenID Connect request.)
             */
            $scope = $requestData['scope'] ?? '';
            $scopes = explode(' ', $scope);
            if(!in_array('openid', $scopes)) {
                return parent::handleRequest($request);
            }

            $responseData = $this->getResponseType()->handleAuthorizationRequest($this, $requestData);

It seems like $requestData can also be of type object and null; however, parameter $requestData of OAuth2\ResponseTypes\ResponseTypeInterface::handleAuthorizationRequest() does only seem to accept array, maybe add an additional type check?

            return $this->getResponseMode()->buildResponse($this, $requestData, $responseData);

It seems like $requestData can also be of type object and null; however, parameter $requestData of OAuth2\ResponseModes\ResponseModeInterface::buildResponse() does only seem to accept array, maybe add an additional type check?

            /**
             * If the sub (subject) Claim is requested with a specific value for the ID Token,
             * the Authorization Server MUST only send a positive response
             * if the End-User identified by that sub value has an active session with the Authorization Server
             * or has been Authenticated as a result of the request.
             * The Authorization Server MUST NOT reply with an ID Token or Access Token for a different user,
             * even if they have an active session with the Authorization Server.
             * Such a request can be made either using an id_token_hint parameter
             * or by requesting a specific Claim Value as described in Section 5.5.1,
             * if the claims parameter is supported by the implementation.
             */


            /**
             * The Authorization Server MUST verify that all the REQUIRED parameters are present and their usage conforms to this specification.
             */

            /**
             * Authorization Server Authenticates the End-User.
             *
             * If the request is valid, the Authorization Server attempts to Authenticate the End-User
             * or determines whether the End-User is Authenticated, depending upon the request parameter values used.
             * The methods used by the Authorization Server to Authenticate the End-User
             * (e.g. username and password, session cookies, etc.) are beyond the scope of this specification.
             * An Authentication user interface MAY be displayed by the Authorization Server,
             * depending upon the request parameter values used and the authentication methods used.
             *
             * The Authorization Server MUST attempt to Authenticate the End-User in the following cases:
             *
             * The End-User is not already Authenticated.
             * The Authentication Request contains the prompt parameter with the value login.
             * In this case, the Authorization Server MUST reauthenticate the End-User
             * even if the End-User is already authenticated.
             *
             * The Authorization Server MUST NOT interact with the End-User in the following case:
             *
             * The Authentication Request contains the prompt parameter with the value none.
             * In this case, the Authorization Server MUST return an error if an End-User is not already Authenticated
             * or could not be silently Authenticated.
             *
             * When interacting with the End-User, the Authorization Server MUST employ appropriate measures
             * against Cross-Site Request Forgery and Clickjacking as, described in Sections 10.12 and 10.13 of OAuth 2.0 [RFC6749].
             */

            /**
             * Authorization Server obtains End-User Consent/Authorization.
             *
             * Once the End-User is authenticated, the Authorization Server MUST obtain an authorization decision
             * before releasing information to the Relying Party.
             * When permitted by the request parameters used,
             * this MAY be done through an interactive dialogue with the End-User
             * that makes it clear what is being consented to or by establishing consent
             * via conditions for processing the request or other means (for example, via previous administrative consent).
             * Sections 2 and 5.3 describe information release mechanisms.
             */

            /**
             * Authorization Server sends the End-User back to the Client with an Authorization Code.
             *
             * An Authentication Response is an OAuth 2.0 Authorization Response message
             * returned from the OP's Authorization Endpoint in response to the Authorization Request message sent by the RP.
             *
             * When using the Authorization Code Flow, the Authorization Response MUST return the parameters
             * defined in Section 4.1.2 of OAuth 2.0 [RFC6749] by adding them as query parameters to the redirect_uri
             * specified in the Authorization Request using the application/x-www-form-urlencoded format,
             * unless a different Response Mode was specified.
             */
        }
        catch (OAuthException $e) {
            /**
             * If the Authorization Server encounters any error, it MUST return an error response, per Section 3.1.2.6.
             */

            return new Response(400, ['content-type' => 'application/json'], $e->jsonSerialize());
        }
}