Support /.well-known/oauth-authorization-server
This allows auto-configuration of the OAuth client.
See more information in this RFC: https://tools.ietf.org/html/rfc8414
Example: https://developer.okta.com/docs/reference/api/oidc/#well-known-oauth-authorization-server
GitLab already provides https://gitlab.com/.well-known/openid-configuration and RFC8414 is newer and in a way backports that to OAuth itself.
oauth-authorization-server
has few more fields, e.g.:
revocation_endpoint
revocation_endpoint_auth_methods_supported
revocation_endpoint_auth_signing_alg_values_supported
introspection_endpoint
introspection_endpoint_auth_methods_supported
introspection_endpoint_auth_signing_alg_values_supported
code_challenge_methods_supported
At the same time openid-configuration
has some extra fields, e.g.:
acr_values_supported
subject_types_supported
id_token_signing_alg_values_supported
id_token_encryption_alg_values_supported
id_token_encryption_enc_values_supported
userinfo_signing_alg_values_supported
userinfo_encryption_alg_values_supported
userinfo_encryption_enc_values_supported
request_object_signing_alg_values_supported
request_object_encryption_alg_values_supported
request_object_encryption_enc_values_supported
display_values_supported
claim_types_supported
claims_supported
claims_locales_supported
claims_parameter_supported
request_parameter_supported
request_uri_parameter_supported
require_request_uri_registration
Because both of them allow additional parameters, I think it is safe to have only one metadata and serve it at both locations. But it would be nice to get automatic configuration for those fields provided in oauth-authorization-server
.