Introspection endpoint is not discovered

[emanueleperuffo]

During discovery, the introspection endpoint is discarded. Apparently it is not implemented in ProviderMetadata.

[ramosbugs]

I see from search results that some OIDC providers define an introspection_endpoint field in their metadata, but I'm not able to find any IETF RFC or spec from the OpenID Connect Foundation that defines this field. This crate only implements published standards, which doesn't appear to include this field at the moment. Please let me know if there's a relevant standard I wasn't able to find.

However, users of this crate can add arbitrary fields to ProviderMetadata by passing a struct that implements AdditionalProviderMetadata as the first generic type parameter to ProviderMetadata instead of using CoreProviderMetadata.

Here's an example:

openidconnect-rs/examples/google.rs

Lines 49 to 73 in d796cca

	// Teach openidconnect-rs about a Google custom extension to the OpenID Discovery response that we can use as the RFC
	// 7009 OAuth 2.0 Token Revocation endpoint. For more information about the Google specific Discovery response see the
	// Google OpenID Connect service documentation at: https://developers.google.com/identity/protocols/oauth2/openid-connect#discovery
	#[derive(Clone, Debug, Deserialize, Serialize)]
	struct RevocationEndpointProviderMetadata {
	revocation_endpoint: String,
	}
	impl AdditionalProviderMetadata for RevocationEndpointProviderMetadata {}
	type GoogleProviderMetadata = ProviderMetadata<
	RevocationEndpointProviderMetadata,
	CoreAuthDisplay,
	CoreClientAuthMethod,
	CoreClaimName,
	CoreClaimType,
	CoreGrantType,
	CoreJweContentEncryptionAlgorithm,
	CoreJweKeyManagementAlgorithm,
	CoreJwsSigningAlgorithm,
	CoreJsonWebKeyType,
	CoreJsonWebKeyUse,
	CoreJsonWebKey,
	CoreResponseMode,
	CoreResponseType,
	CoreSubjectIdentifierType,
	>;

[emanueleperuffo]

Hi @ramosbugs .

Thanks for the explanation. I was fooled by the fact that oauth2's Client declares introspection_url and I thought that this library was supposed to pass everything to the client upon creation.

You are completely right about the standards, I assumed that everything that the openid-configuration endpoint returns is standard, which is not true. My fault, sorry.

I see that there is RFC 8414, but it's a Proposed Standard.

Thank you very much for pointing me to the example, which demonstrates clearly how I can move forward.

Feel free to close the issue.

[ramosbugs]

I see that there is RFC 8414, but it's a Proposed Standard.

Oh, this may be sufficient justification to include it! The introspection, revocation, and device authorization grant RFCs are all Proposed Standards as well.

I'll take a closer look and follow up.

[ramosbugs]

I've looked over RFC 8414, and I'm a little hesitant to mix fields from this newer OAuth2 standard with the fields from the original OIDC Discovery standard. It's possible that some OpenID Connect providers will add their own fields that conflict with this RFC 8414, but that are still compatible with OIDC Discovery (which permits arbitrary additional fields to be added). I think the simplest solution for now would be to add an example to the crate (similar to the Google one for the revocation endpoint) that illustrates how to use AdditionalProviderMetadata to get the introspection_endpoint.

I'm also trying to figure out how to make this interact cleanly with the new typestates approach from oauth2 5.0 that only makes functions callable when the relevant endpoints have been set. The dynamic nature of OIDC discovery makes that more challenging.

[ronnybremer]

Oh, this may be sufficient justification to include it! The introspection, revocation, and device authorization grant RFCs are all Proposed Standards as well.

@ramosbugs It looks like the device authorization grant workflow has been fully approved by RFC 8628, it also adds the appropriate discovery document section and request parameters, see RFC 8628, Section 7.

[ramosbugs]

@ramosbugs It looks like the device authorization grant workflow has been fully approved by RFC 8628, it also adds the appropriate discovery document section and request parameters, see RFC 8628, Section 7.

Unfortunately, this refers to the RFC 8414 OAuth 2.0 Authorization Server Metadata, not the OpenID Connect Discovery metadata. That's an entirely different discovery protocol not supported by this crate.

[ronnybremer]

@ramosbugs Thank you for your feedback and you are absolutely right. I was too excited to see it being finalized a while back and missed that crucial part. Guess I will go back to wait for the spec to be finally integrated into the Discovery metadata.