apereo/cas · error
unsupported_response_type
unsupported_response_type
Error message
Unsupported response_type: [%s]
What it means
The /authorize request must carry a response_type that CAS recognizes (code, token, id_token, device_code, etc., from OAuth20ResponseTypes). When the response_type parameter is missing or is not one of the supported enum values, CAS rejects the request with error=unsupported_response_type. The first branch of verifyResponseType handles a missing parameter; this message covers a present-but-unknown value.
Solutions
- Send a supported response_type such as code (authorization code flow) exactly as specified by the OAuth2 spec.
- If you need OIDC response types (id_token, code id_token), enable the CAS OIDC support module and use the /oidcAuthorize endpoint.
- Fix typos in the client's authorization request URL (e.g. response_type=code, not response_type=codes).
- Verify the request parameter name is response_type and that the request-parameter resolver is reading it (custom resolvers may drop it).
Example fix
// before GET /cas/oauth2.0/authorize?client_id=app&redirect_uri=...&response_type=code_token // after GET /cas/oauth2.0/authorize?client_id=app&redirect_uri=...&response_type=code
Defensive patterns
Strategy: validation
Validate before calling
const SUPPORTED = ['code','token','id_token','device_code'];
if (!SUPPORTED.includes(responseType)) {
throw new Error(`Unsupported response_type: ${responseType}`);
} Type guard
const isSupportedResponseType = (v) => ['code','token','id_token','device_code'].includes(v);
Prevention
- Centralize the authorization URL builder in one function with response_type=code hardcoded unless you specifically need another flow.
- Add a startup-time assertion in the client that its configured flow maps to a supported response_type.
- Avoid copying response_type values from other IdPs' documentation without checking CAS's OAuth20ResponseTypes enum.
When it happens
Trigger: GET /oauth2.0/authorize?response_type=codes (typo) or response_type=code_token (unsupported combination) or any response_type outside OAuth20ResponseTypes.values().
Common situations: Typo in the client's authorization URL; client library emits OpenID hybrid values (e.g. code id_token) while the CAS build lacks the OIDC module; custom response types from another provider carried over during migration.
Related errors
- unauthorized_client
- Response type [ ] or grant type [ ] is not supported.
- Response type not authorized for service
- Subject token type is not supported
- Actor token type is not supported
AI-assisted analysis of apereo/cas@e7288fc434 (2026-09-08).
Data as JSON: /api/errors/8e3849492fc59d75.
Report an issue: GitHub.
Appendix: source
Thrown at support/cas-server-support-oauth-core-api/src/main/java/org/apereo/cas/support/oauth/validator/authorization/BaseOAuth20AuthorizationRequestValidator.java:168
if (!OAuth20Utils.checkCallbackValid(registeredService, redirectUri)) {
LOGGER.warn("Redirect URI [{}] found in the request is not authorized for registered service [{}].",
redirectUri, registeredService.getServiceId());
setErrorDetails(context, OAuth20Constants.INVALID_REQUEST,
String.format("Redirect URI [%s] found in the request is not authorized for this service", redirectUri), false);
return false;
}
return true;
}
private boolean verifyResponseType(final WebContext context, final String responseType) {
if (StringUtils.isBlank(responseType)) {
setErrorDetails(context, OAuth20Constants.UNSUPPORTED_RESPONSE_TYPE,
String.format("Missing required parameter: [%s]", OAuth20Constants.RESPONSE_TYPE), true);
return false;
}
if (!OAuth20Utils.checkResponseTypes(responseType, OAuth20ResponseTypes.values())) {
LOGGER.warn("Response type [{}] is not found in the list of supported values [{}].",
responseType, OAuth20ResponseTypes.values());
setErrorDetails(context, OAuth20Constants.UNSUPPORTED_RESPONSE_TYPE,
String.format("Unsupported response_type: [%s]", responseType), true);
return false;
}
return true;
}
}
View on GitHub (pinned to e7288fc434)