Page History

...

The public (mobile) client generates a 'code_verifier' value and includes a related 'code_challenge' and optional 'code_challenge_method' to the authorization service. The authorization service will save the code_challenge value, with the help of the registered AuthorizationCodeDataProvider into an instance of ServerAuthorizationCodeGrant. The client will next request a token providing the 'code_verifier' - which will be compared by AuthorizationCodeGrantHandler with the original 'code_challenge' value. By default, the 'code_challenge' is expected to be equal to the original 'code_verifier', but the grant handler can be registered with a custom org.apache.cxf.rs.security.oauth2.grants.code.CodeVerifierTransformer.  CXF ships a DigestCodeVerifier which implements a transformation mentioned in the extension.

From CXF 3.5.1/3.4.6, the AuthorizationCodeGrantHandler has a "requireCodeVerifier" property, which when set to "true" requires that all clients must specify a code verifier. This aligns with the OAuth 2.1 specification.

Form Post Response Mode

Form Post Response Mode was originally introduced for OpenId Connect but has been generally recommended recently as a possibly safer option of returning OAuth2 Authorization Service responses to clients. Starting from CXF 3.1.9, if a client sends a "response_mode=form_post" parameter during the original redirect, CXF AuthorizationCodeService will return an OOBAuthorizationResponse with its 'redirectUri' property set - which a JSP/etc handler will convert to an HTML form which will re-post the data to the client callback address.

...