The OAuth Authorization Server Metadata Specification, RFC 8414 is supported by the Curity Identity Server.
This means that a metadata endpoint can be enabled so that an OAuth client can obtain the information needed to interact with Curity, including its endpoint locations and authorization server capabilities.
However, the metadata endpoint is disabled by default. To enable it, inside the Token Service configuration, turn on the expose-metadata configuration.
expose-metadata
Once enabled, a HTTP client can obtain the OAuth Server Metadata by making a request to https://your-server/.well-known/oauth-authorization-server/<issuer>, where the last path component, <issuer>, is the Token Service’s issuer ID (which is normally the path to the anonymous endpoint, but can be explicitly set by configuring an issuer-override on the Token Service).
https://your-server/.well-known/oauth-authorization-server/<issuer>
<issuer>
issuer-override
Warning
Because of the way the metadata endpoint path must be constructed, there could be conflicts between different Token services, for example, if their anonymous endpoint path happens to be the same. In such case, Curity will log a warning and only one of the endpoints will become available.
This means that an OAuth client can discover everything it needs to self-configure (including the authorization_endpoint, token_endpoint, jwks_uri and many other useful parameters) after being informed of only the OAuth authorization server’s issuer identifier.
authorization_endpoint
token_endpoint
jwks_uri
{ "introspection_endpoint_auth_signing_alg_values_supported": [ "PS384", "RS384", "ES256", "RS256", "EdDSA", "PS256", "PS512", "RS512" ], "request_parameter_supported": true, "pushed_authorization_request_endpoint": "https://localhost:8443/dev/oauth/authorize/par", "authorization_response_iss_parameter_supported": true, "claims_parameter_supported": true, "introspection_endpoint": "https://localhost:8443/introspection", "scopes_supported": [ "address", "read", "admin_read", "phone", "openid", "profile", "urn:se:curity:scopes:admin:api", "admin_write", "write", "email" ], "issuer": "https://localhost:8443/dev/oauth/anonymous", "acr_values_supported": [ "urn:se:curity:authentication:google:google1", "urn:se:curity:authentication:totp:totp", "urn:se:curity:authentication:html-form:phpass", "urn:se:curity:authentication:sms:sms2fa" ], "service_documentation": "https://localhost/developer-documentation-url", "authorization_endpoint": "https://localhost:8443/dev/oauth/authorize", "introspection_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic", "private_key_jwt" ], "require_pushed_authorization_requests": false, "claim_types_supported": [ "normal" ], "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic", "private_key_jwt" ], "tls_client_certificate_bound_access_tokens": false, "response_modes_supported": [ "fragment", "fragment.jwt", "jwt", "form_post", "query", "query.jwt", "form_post.jwt" ], "token_endpoint": "https://localhost:8443/dev/oauth/token", "response_types_supported": [ "code", "code id_token", "code id_token token", "code token", "id_token", "id_token token", "token" ], "revocation_endpoint_auth_signing_alg_values_supported": [ "PS384", "RS384", "ES256", "RS256", "EdDSA", "PS256", "PS512", "RS512" ], "revocation_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic", "private_key_jwt" ], "request_uri_parameter_supported": true, "grant_types_supported": [ "refresh_token", "implicit", "client_credentials", "password", "authorization_code", "urn:ietf:params:oauth:grant-type:pre-authorized_code" ], "ui_locales_supported": [ "sv", "pt", "en" ], "revocation_endpoint": "https://localhost:8443/revoke", "token_endpoint_auth_signing_alg_values_supported": [ "PS384", "RS384", "ES256", "RS256", "EdDSA", "PS256", "PS512", "RS512" ], "require_request_uri_registration": true, "require_signed_request_object": false, "code_challenge_methods_supported": [ "S256", "plain" ], "jwks_uri": "https://localhost:8443/dev/oauth/anonymous/jwks", "assisted_token_endpoint": "https://localhost:8443/assisted-token", "claims_locales_supported": [ "sv", "pt", "en" ], "authorization_signing_alg_values_supported": [ "RS256" ], "request_object_signing_alg_values_supported": [ "RS256", "none" ], "prefix_scopes_supported": [] }
Note
Not all OpenID Connect parameters are shown in the OAuth Metadata response, even if OpenID has been enabled in the Token Service. To retrieve the full OpenID metadata, use the OpenID Connect-specific endpoint which is discussed in the next section.
Normally, enabling OAuth metadata is as easy as enabling expose-metadata in the configuration. However, if there is more than one endpoint configured for each endpoint kind (e.g. more than one authorization_endpoint), then one must be selected explicit for each ambiguous endpoint kind.
All exposed endpoints may be explicitly selected, and their corresponding base URL may be overridden if necessary (the absolute URLs are normally resolved from the server’s own base URL configuration, or from the request if that’s not configured).
The OpenID Connect configuration can be used to enable the OpenID Connect metadata endpoint.
Enabling this endpoint requires a few conditions to be met in order for the metadata information to be consistent. The configuration will not validate if these conditions are not met:
client-credentials
code
resource-owner-password-credentials
token-exchange
oauth-authorize
oauth-token
oauth-userinfo
oauth-assisted-token
oauth-revoke
oauth-introspect
If all of these conditions are met, then the metadata can be obtained by requesting the subroute /.well-known/openid-configuration under the anonymous endpoint. For example, if the anonymous endpoint is configured to be ~, then this would be at /~/.well-known/openid-configuration on the host that is serving the OAuth profile’s anonymous endpoint.
/.well-known/openid-configuration
~
/~/.well-known/openid-configuration
If this endpoint were hosted on a service that used the HTTPS protocol, had a hostname of localhost and was listening on port 8443, then the metadata would be accessible at https://localhost:8443/~/.well-known/openid-configuration.
The metadata in this response is mostly defined by the OpenID Connect and OAuth metadata standards where applicable. The included metadata and its meaning is described in the following table:
OpenID Connect Metadata
OpenID Connect metadata fields that are returned depending on various configuration
jwks
assisted-token
openid
The response types that the OAuth profile supports. The elements of the array will be as summarized in the following table:
code id_token
code id_token token
id_token
implicit
id_token token
token
code token
code token id_token
query
fragment
The grant types or “flows” that are supported by the OAuth profile. The elements of the array will be as summarized in the following table:
authorization_code
refresh_token
password
client_credentials
https://curity.se/grant/accesstoken
https://curity.se/grant/assisted-token
backchannel-authentication
urn:openid:params:grant-type:ciba
pairwise
public
RS256
client_secret_post
client_secret_basic
normal
$IDSVR_HOME/usr/share/messages/overrides
ui_locales_supported
S256
plain
Bearer
sid
poll
An example of the OpenID Connect metadata is shown in Listing 128.
{ "introspection_endpoint": "https://localhost:8443/introspection", "scopes_supported": [ "read", "admin_read", "openid", "profile", "admin_write", "write", "email" ], "issuer": "https://spruce:8443/dev/oauth/anonymous", "acr_values_supported": [ "urn:se:curity:authentication:google:google1", "urn:se:curity:authentication:sms:sms2fa", "urn:se:curity:authentication:sms:sms1", "urn:se:curity:authentication:html-form:html2fa", "loa1" ], "authorization_endpoint": "https://localhost:8443/dev/oauth/authorize", "introspection_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ], "service_documentation": "https://localhost/developer-documentation-url", "claim_types_supported": [ "normal" ], "token_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ], "response_modes_supported": [ "fragment", "query" ], "token_endpoint": "https://localhost:8443/dev/oauth/token", "response_types_supported": [ "code", "id_token", "token" ], "revocation_endpoint_auth_methods_supported": [ "client_secret_post", "client_secret_basic" ], "grant_types_supported": [ "refresh_token", "implicit", "client_credentials", "password", "https://curity.se/grant/accesstoken", "authorization_code", "urn:openid:params:grant-type:ciba", "https://curity.se/grant/assisted-token" ], "backchannel_authentication_endpoint": "https://localhost:8443/bc-auth", "backchannel_token_delivery_modes_supported": [ "poll" ], "backchannel_authentication_request_signing_alg_values_supported": [ "RS256" ], "ui_locales_supported": [ "sv", "en" ], "revocation_endpoint": "https://localhost:8443/revoke", "userinfo_endpoint": "https://localhost:8443/dev/oauth/userinfo", "code_challenge_methods_supported": [ "S256", "plain" ], "jwks_uri": "https://localhost:8443/dev/oauth/anonymous/jwks", "subject_types_supported": [ "public" ], "id_token_signing_alg_values_supported": [ "S256" ], "assisted_token_endpoint": "https://localhost:8443/assisted-token", "claims_locales_supported": [ "sv", "en" ] }
OpenID Connect Metadata contains all of the parameters included in the OAuth metadata, but with several more parameters added, such as userinfo_endpoint and backchannel_authentication_endpoint which are OpenID-specific features.
userinfo_endpoint
backchannel_authentication_endpoint
It is not possible to configure both OAuth metadata’s and OpenID metadata’s jwks-uri-override at the same time. Only one of them must be configured because only one JWKS URI should exist - whichever was configured, or <oidc-metadata-endpoint>/jwks by default. Trying to configure both results in a configuration validation error.
jwks-uri-override
<oidc-metadata-endpoint>/jwks