search

ramosbugs / openidconnect-rs

OpenID Connect Library for Rust
MIT License
426 stars 103 forks source link

Introspection endpoint is not discovered #141

Open emanueleperuffo opened 11 months ago

emanueleperuffo commented 11 months ago

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

ramosbugs commented 11 months ago

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: https://github.com/ramosbugs/openidconnect-rs/blob/d796cca6f5c28f75a6f36ff6861cabcd845bfd7e/examples/google.rs#L49-L73

emanueleperuffo commented 11 months ago

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 commented 11 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

@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 commented 7 months ago

@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.