Ignore unsupported scope values, answer token errors with RFC 6749 codes, and state the granted scope

Unknown scope values are now ignored at the authorization and PAR
endpoints instead of failing the request with invalid_scope (OpenID4VCI
1.0 section 5.1.2, OpenID Connect Core 1.0 section 3.1.2.1, RFC 6749
section 3.3); ScopeRule logs the values it ignored. The id of a
credential configuration which can be requested through
authorization_details only is ignored as a scope the same way. A
credential issuance request left naming no credential configuration, by
scope or by authorization_details, is refused with invalid_scope
(OfferedCredentialsRule), with or without an offer.

The token endpoint answers with the error codes of RFC 6749 section
5.2: invalid_grant for a code which can not be decrypted or is
malformed, was issued to another client, or comes with another
redirect_uri; invalid_client (401, with League's challenge when the
Authorization header was used) where client authentication is missing
or fails, at the PAR endpoint too (RFC 9126 section 2.3). The caller is
authenticated from its own credentials and then compared with the
code's client, rather than authenticated against that client, so a
client disabled or expired since its code was issued can no longer
redeem it; the redirect_uri is compared, as sent, with the
authorization request's alone, no longer held to the registration
again.

Token responses, and implicit responses which return an access token,
state the granted scopes in scope (RFC 6749 sections 5.1 and 4.2.2),
every time, leaving out the ids of authorization-details-only
configurations.

ErrorResponder keeps every OAuth error_description, in a JSON body or a
redirect, to the characters RFC 6749 allows, as Routes already did for
the VCI endpoints, and passes League's invalid_client challenge on in
JSON error responses.

Upgrade notes for the OpenID Connect visible changes; the OpenID4VCI
compliance matrix closes G1 and G23 (rows 12 and 20).

Author: cicnavi

config/module_oidc.php.dist

@@ -175,8 +175,8 @@ $config = [
      * either: OpenID Connect Core section 11 defines it as a request for a
      * refresh token, so there is nothing to grant. It is then left out of
      * 'scopes_supported', a client can not be registered with it, and a
-     * request carrying it is refused as 'invalid_scope' like any other
-     * unsupported scope.
+     * request carrying it is served without it, the scope value being ignored
+     * like any other unsupported one.
      *
      * If not set, every grant type is enabled.
      */

conformance-tests/openid4vci-1_0-compliance.md

@@ -22,7 +22,7 @@ When you change PAR / request_uri behaviour, keep this table in sync.
 
 | # | Requirement (spec ref) | Enforced in | Covered by test |
 |---|------------------------|-------------|-----------------|
-| 3 | Authenticate the client the same way as at the token endpoint (§2.1, step 1). | `PushedAuthorizationController::__invoke()` via `AuthenticatedOAuth2ClientResolver::forAnySupportedMethod()`; confidential clients must authenticate. | `PushedAuthorizationControllerTest`: `testClientAuthenticationFailureThrows`, `testConfidentialClientMustAuthenticate`. |
+| 3 | Authenticate the client the same way as at the token endpoint (§2.1, step 1). | `PushedAuthorizationController::__invoke()` via `AuthenticatedOAuth2ClientResolver::forAnySupportedMethod()`; confidential clients must authenticate. A client which fails to, or a confidential one which presents no authentication, is refused with `invalid_client` as at the token endpoint (§2.3, RFC 6749 section 5.2), with the challenge of its scheme when it used the Authorization header (`ErrorResponder::forExceptionJson()`). | `PushedAuthorizationControllerTest`: `testClientAuthenticationFailureThrows`, `testConfidentialClientMustAuthenticate`. |
 | 4 | MUST reject the request if the `request_uri` parameter is provided (§2.1 step 2; §2.1-1 "MUST NOT be provided"). | `PushedAuthorizationController::__invoke()` rejects `request_uri` in the body. | `PushedAuthorizationControllerTest::testRejectsRequestUriInBody`. |
 | 5 | MUST validate the pushed request as it would an authorization request at the authorization endpoint (§2.1 step 3). | `PushedAuthorizationController::__invoke()` runs the authorization request-rule pipeline (`StateRule`, `ClientRedirectUriRule`, `RequestObjectRule`, `ResponseModeRule`, `ScopeRule`, `RequiredOpenIdScopeRule`, `CodeChallengeRule`, `CodeChallengeMethodRule`, `DpopJktRule`, `IssuerStateRule`, `AuthorizationDetailsRule`, `OfferedCredentialsRule`); `resolveParametersToPersist()` refuses a request without `response_type`, which nothing could supply at redemption (row 23). | `PushedAuthorizationControllerTest::testHandlesValidParRequest`, `testRefusesAPushedRequestWithoutAResponseType` (and the rule-specific tests for each rule). |
 

conformance-tests/rfc9126-par-compliance.md

@@ -24,6 +24,11 @@ is refused unless `plain_oauth2_authorization_code_enabled` turns such requests
 on; it then gets no ID token. See
 [Configuration](3-oidc-configuration.md#plain-oauth-20-authorization-code-requests).
 
+Scope values the OP does not support are ignored rather than refused (OpenID
+Connect Core 1.0 section 3.1.2.1), and the OP log names them. The token
+response states the scopes the access token grants in `scope` (RFC 6749 section
+5.1), so a client learns which of those it asked for it got.
+
 Authorization request parameters can be sent as plain parameters, by value as a
 Request Object (`request`, OpenID Connect Core / JAR), or by reference
 (`request_uri`) — either via Pushed Authorization Requests (PAR, RFC 9126) or a
@@ -219,6 +224,10 @@ Currently implemented OpenID4VCI features:
   of its configuration, and the token response leaves `claims` out of the
   details it returns. A credential configuration whose metadata states no
   `scope` can be requested through authorization details only.
+  - Scopes: a scope value the issuer does not support is ignored (OpenID4VCI
+  1.0 section 5.1.2), and a credential request which is then left naming no
+  credential configuration, by `scope` or by authorization details, is refused
+  with `invalid_scope`.
 - Supported Credential Formats
   - JWT VC JSON (`jwt_vc_json`): W3C VCDM v1.1 Verifiable Credentials encoded as
   JWT.

docs/1-oidc.md

@@ -589,9 +589,10 @@ OpenID Connect Discovery 1.0 section 3 has list the standard scopes "if
 supported"), from the scopes a client can be registered with (Dynamic Client
 Registration filters it out, the client form does not offer it, and the default
 set for a scope-less dynamic registration no longer contains it), and an
-authorization request carrying it is refused as `invalid_scope`, the way the
-module answers any scope it does not support. A client which relies on refresh
-tokens should therefore not be registered with such an OP.
+authorization request carrying it is served without it, the way the module
+treats any scope value it does not support (it ignores the value and logs it).
+A client which relies on refresh tokens should therefore not be registered with
+such an OP.
 
 Why disable the implicit grant: OAuth 2.0 Security Best Current Practice
 (RFC 9700, section 2.1.2) has clients avoid the implicit grant and every

docs/3-oidc-configuration.md

@@ -130,7 +130,8 @@ deployment behaves as before; a grant type taken off the list is neither
 advertised, nor registrable, nor served, even for a client registered with it
 earlier. Without `refresh_token` the `offline_access` scope is not supported
 either: it leaves `scopes_supported` and the registrable scopes, and a request
-for it is refused as `invalid_scope`. (Related tightening: a Verifiable
+for it is served without it (see the item on unsupported scope values below).
+(Related tightening: a Verifiable
 Credential configuration id equal to a standard OpenID Connect scope name —
 `openid`, `offline_access`, `profile`, `email`, `address`, `phone` — is now
 refused while issuance is enabled, since such an id becomes a scope which would
@@ -734,6 +735,47 @@ answers any unexpected failure while processing a request in the token error
 format (`{"error": "server_error", ...}`, HTTP 500, with the cause in the OP
 log rather than in the response) instead of with SimpleSAMLphp's HTML error
 page.
+- The token endpoint now refuses requests with the error codes of RFC 6749
+section 5.2. An authorization code which can not be decrypted or is malformed,
+one issued to another client, and a `redirect_uri` which differs from the
+authorization request's get `invalid_grant` (HTTP 400). They got
+`invalid_request`, or `access_denied` (HTTP 401) where a client which
+authenticated as itself presented another client's code. The `redirect_uri`
+is now compared with the authorization request's alone, as RFC 6749 section
+4.1.3 has it, and no longer with the client's registration as well. A client
+which presents no client
+authentication it can be authenticated by, or a confidential client which
+presents none (the `none` method), gets `invalid_client` (HTTP 401, with a
+`WWW-Authenticate: Basic realm="OAuth"` challenge when it sent an
+`Authorization` header), where it got `access_denied` (HTTP 401); the PAR
+endpoint now refuses such a client the same way (RFC 9126 section 2.3). The
+client is authenticated from its own credentials, rather than taken from the
+code it presents, so a client which has been disabled, or has expired, since
+its code was issued can no longer redeem it. A client which compares the
+`error` member with the old values needs the new ones.
+- Scope values the OP does not support are now ignored at the authorization and
+PAR endpoints, rather than refused: the request goes on with the scopes it
+asked for which the OP supports, and the OP log names the ones it ignored
+(`notice` level). Previously any one of them failed the request with
+`invalid_scope`. OpenID Connect Core 1.0 (section 3.1.2.1) has an OpenID
+Provider ignore scope values it does not understand, and RFC 6749 (section
+3.3) lets an authorization server grant fewer scopes than were requested. A
+request left without `openid` is still refused (`invalid_request`), unless it
+is a plain OAuth 2.0 request the deployment allows. A client with a mistyped
+scope therefore now gets a token without that scope instead of an error, and
+the token response says which scopes it got (next item). The `scope` of a
+refresh token request is checked as before (RFC 6749 section 6).
+- Token responses now carry `scope`, the scopes the access token grants, and so
+does an implicit response which returns an access token (`id_token token`).
+RFC 6749 (sections 5.1 and 4.2.2) requires it whenever the scopes granted
+differ from those requested, as they do when a scope value was ignored or the
+client is not registered for a scope it asked for; the OP states it every
+time. A client which does not read the member is unaffected.
+- The `error_description` of every OAuth error response, in a JSON body or sent
+back to the redirect URI, now keeps only the characters RFC 6749 allows in it
+(sections 4.1.2.1, 4.2.2.1 and 5.2: printable ASCII except the double quote and
+the backslash); any other is dropped. Previously a description could carry
+them, a double quote quoting a value, for instance.
 - The reuse checks of `private_key_jwt` client assertions (in the protocol
 cache) and of OpenID Federation Request Objects (in the federation cache) now
 fail the request with `server_error` when the cache does not store the record

docs/6-oidc-upgrade.md

@@ -77,16 +77,21 @@ public function __invoke(ServerRequestInterface $request): ResponseInterface
                 ->withHeader('Allow', HttpMethodsEnum::POST->value);
         }
 
-        // Authenticate the client in the same way as at the token endpoint.
+        // Authenticate the client in the same way as at the token endpoint, and refuse it the same way:
+        // `invalid_client` (RFC 9126 section 2.3, RFC 6749 section 5.2).
         $resolvedAuth = $this->authenticatedOAuth2ClientResolver->forAnySupportedMethod($request);
         if (is_null($resolvedAuth)) {
-            throw OidcServerException::accessDenied('Client authentication failed.');
+            throw OidcServerException::invalidClient($request);
         }
 
         $client = $resolvedAuth->getClient();
 
         if ($resolvedAuth->getClientAuthenticationMethod()->isNone() && $client->isConfidential()) {
-            throw OidcServerException::accessDenied('Confidential client must authenticate.');
+            $this->logger->warning(
+                'Pushed authorization request rejected: confidential client used the "none" authentication method.',
+                ['client_id' => $client->getIdentifier()],
+            );
+            throw OidcServerException::invalidClient($request);
         }
 
         $bodyParams = $request->getParsedBody();

src/Controllers/PushedAuthorizationController.php

@@ -30,6 +30,7 @@ public function build(): TokenResponse
             $this->idTokenBuilder,
             $this->privateKey,
             $this->loggerService,
+            $this->moduleConfig,
         );
         $tokenResponse->setEncryptionKey($this->moduleConfig->getEncryptionKey());
 

src/Factories/TokenResponseFactory.php

@@ -1218,10 +1218,10 @@ public function getForcedAcrValueForCookieAuthentication(): ?string
      *
      * OpenID Connect Core 1.0 section 11 defines 'offline_access' as a request for a refresh token, so without
      * the refresh token grant (see OPTION_ENABLED_GRANT_TYPES) the scope has nothing to grant and is left out: it
-     * is not advertised, a client can not be registered with it, and a request carrying it is refused as
-     * 'invalid_scope' like any other unsupported scope. The name is taken out of the merged set, and a private
-     * scope (validate()) or Verifiable Credential configuration (getVciScopes()) named after a standard scope is
-     * refused, so nothing merged later can put it back.
+     * is not advertised, a client can not be registered with it, and a request carrying it is served without
+     * it, the value being ignored like any other unsupported one (ScopeRule). The name is taken out of the merged
+     * set, and a private scope (validate()) or Verifiable Credential configuration (getVciScopes()) named after a
+     * standard scope is refused, so nothing merged later can put it back.
      *
      * @throws \Exception
      */

src/ModuleConfig.php

@@ -119,6 +119,7 @@ public static function unsupportedResponseType(
      * @param string|null $redirectUri An HTTP URI to redirect the user back to
      * @param string|null $state
      * @param \SimpleSAML\Module\oidc\Server\ResponseModes\ResponseModeInterface|null $responseMode
+     * @param string|null $hint What is wrong, in place of the hint derived from the scope
      * @return static
      * @psalm-suppress LessSpecificImplementedReturnType
      */
@@ -127,15 +128,11 @@ public static function invalidScope(
         ?string $redirectUri = null,
         ?string $state = null,
         ?ResponseModeInterface $responseMode = null,
+        ?string $hint = null,
     ): static {
-        if (empty($scope)) {
-            $hint = 'Specify a scope in the request or set a default scope';
-        } else {
-            $hint = sprintf(
-                'Check the `%s` scope',
-                htmlspecialchars($scope, ENT_QUOTES, 'UTF-8', false),
-            );
-        }
+        $hint ??= empty($scope) ?
+        'Specify a scope in the request or set a default scope' :
+        sprintf('Check the `%s` scope', htmlspecialchars($scope, ENT_QUOTES, 'UTF-8', false));
 
         $e = self::create(
             'The requested scope is invalid, unknown, or malformed',