Skip to content

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.