Custom providers, using issuer URL about rocket_oauth2 HOT 8 CLOSED

Are you also doing Issuer Discovery (https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery)? That complicates this a lot, because you would need to look up the provider information for each attempted login request.

from rocket_oauth2.

I don't need the full discovery protocol including webfinger etc.
My plan for now is to minimize the configuration effort. So for what I have in mind, it'd be sufficient to set the config URI once (before startup in a config file, or as command line parameter).
However, the data should be loaded in a lazy fashion, on the first request, so startup doesn't depend on the OP being online at that point.

from rocket_oauth2.

I did some preliminary work on a possible Provider trait and the other changes that causes.

/// A `Provider` can retrieve authorization and token exchange URIs specific to
/// an OAuth service provider.
pub trait Provider: Send + Sync + 'static {
    /// Returns the authorization URI associated with the service provider.
    fn auth_uri(&self) -> Cow<'_, str>;
    /// Returns the token exchange URI associated with the service provider.
    fn token_uri(&self) -> Cow<'_, str>;
}

This would allow users to implement Provider on custom types, perhaps containing something like a Lazy<(String, String)>.

But because the client_id and client_secret must still be specified "ahead of time", I think it only helps with your use case of looking up the provider URIs lazily. I am actually a little confused after reading through it again - in what situation would a provider be offline at startup but come online later, and that you can hardcode a 'discovery URI' but not the auth and token URIs?

from rocket_oauth2.

Ok, I should clarify my use case:

Coming from a Java dev background, the systems I usually deploy consist of an IDP/OP (Keycloak), a server backend, and other services. So each environment (production, staging, test, development) has its own set of services, including the IDP.

So in essence, I keep redeploying these through a CI pipeline, and having startup dependencies between the services makes life much harder, as you can imagine (I'd have to make sure the now-written-in-rust backend can only start after the IDP has booted entirely).

from rocket_oauth2.

I still feel like I am missing something here; from my perspective, this solution only adds complexity on all sides. Instead of two URIs in a config file, there is now one URI in a config file plus new and existing infrastructure to discover the two real URIs spread across at least three different units (Keycloak, this library, and your application code).

The value I see for Provider being a trait is to support "the identity provider is not known at startup or might change over the lifetime of the application", which seems plausible enough to support. It will work for your use case as well, but I am not as convinced it is necessary there.

from rocket_oauth2.

Provider is now a trait in ed8f844, in the master branch. Can you confirm that the Provider trait works for your use case?

from rocket_oauth2.

Hi Jeb,
Sorry, I wasn't able to work on my side project for the last couple of days, so that's why Iv'e been a little quiet on the topic.
I just had a look at the change, it it's looking really good to me - this will allow me to pull the provider info lazily, on demand. I hope to get back to my rocket project at the end of the week; I'll report how the change works out for me then when I adapt my code accordingly.

Thanks for the effort!

Cheers,
Uwe

from rocket_oauth2.

This functionality and more can be accomplished now that Provider is a trait, so I'm going to close this. Thanks for the request and discussion!

from rocket_oauth2.