use the implicit grant or another response type that issues access tokens in the authorization response.

Condition: Unless access-token injection is prevented and the identified token-leakage vectors are mitigated.

clients SHOULD NOT use the implicit grant

use the code response type or another response type that causes access tokens to be issued in the token response.

Condition: Instead of the implicit grant or other response types issuing access tokens in the authorization response.

Clients SHOULD instead use the response type code

allow additional grant_types values defined through the OAuth 2.0 grant type extension process.

Condition: For values beyond those listed by RFC 7591.

Authorization servers MAY allow for other values

take steps to prevent a client from registering an inconsistent combination of grant_types and response_types.

Condition: When supporting both metadata fields.

SHOULD take steps to ensure that a client cannot register itself into an inconsistent state

implement and use the grant_types client metadata field.

Condition: Unless another applicable specification states otherwise.

The implementation and use of all client metadata fields is OPTIONAL, unless stated otherwise.

use the resource owner password credentials grant.

The resource owner password credentials grant [RFC6749] MUST NOT be used.

document every correspondence between grant_types and response_types.

Condition: When introducing a new value for either parameter.

MUST document all correspondences between these two parameter types

equal the grant_type parameter value defined for the grant.

Condition: When the grant uses the token endpoint.

the value of this parameter MUST be the same as the value of the "grant_type" parameter