Using Auth0 as IDP and manage on Client the redirection.

[AlexandreRoba]

Using Auth0 as IDP and manage on Client the redirection.

[AlexandreRoba]

IIRC the original ideas was to allow one to manually start a login process (e.g. from your own component) with some additional options.

That is an excellent idea! I could leverage this. Then I guess this is where it happens. It never takes the one coming from the inner config and takes the one from the "manual" start and this override the one set on the OAuth2 component. I will look into this.

[ctron]

@kate-shine @AlexandreRoba there's a PR for this now: #24 … it would be great if you could give it a try.

You should be able to do this using:

[patch.crates-io]
yew-oauth2 = { git = "https://github.com/ctron/yew-oauth2", rev = "4342e94907799da7d305492e0b7df3a8326373b4" } 

[ctron]

Taking a closer look at the code, I think everything should already be there:

yew-oauth2/src/agent/mod.rs

Lines 441 to 450 in 62187a9

	let login_context = client.make_login_context(config, redirect_url.clone())?;
	SessionStorage::set(STORAGE_KEY_CSRF_TOKEN, login_context.csrf_token)
	.map_err(|err| OAuth2Error::StartLogin(err.to_string()))?;
	SessionStorage::set(STORAGE_KEY_LOGIN_STATE, login_context.state)
	.map_err(|err| OAuth2Error::StartLogin(err.to_string()))?;
	SessionStorage::set(STORAGE_KEY_REDIRECT_URL, redirect_url)
	.map_err(|err| OAuth2Error::StartLogin(err.to_string()))?;

I am not sure why it doesn't work … I guess you will need to debug this.

[AlexandreRoba]

@ctron thanks a lot for this. I was dragged into other issues. i will give it a try this we.

[ctron]

There's a LoginOptions struct which allows to supply the redirect URL:

yew-oauth2/src/components/context/mod.rs

Line 43 in c60380d

pub options: Option<LoginOptions>,

It defaults to the current URL. I am not sure this is exposed at the moment. But I think this should be the right feature to leverage.

[ctron]

Ah, double checking … it's exposed as part of the OAuth2 component.

[ctron]

Ah … and triple checking (should have done that first) … that was you already use. Hm …

[ctron]

Ok, checking the Auth0 docs, that looks like an interesting limitation. IIRC Keycloak does allow a prefix, and even allow for certain wildards.

So I guess you need to follow the idea of Auth0, and encode this somewhere in a cookie, session, or state variable.

[AlexandreRoba]

Hi @ctron,

Yes indeed. Unless I'm mistaken but I have set LoginOptions but it does not seems to be taken into account. :( It is always sets the returnUrl as the one of the ressource.

My second problem is to be able to capture the url of the ressource that I'm trying to access in order to be able to pass it in a state or a cookie to the authorization endpoint. Is this supported? An idea on how to do this?

[AlexandreRoba]

Hi @ctron. I'm trying to find out what is going on. I have forked the solution and set couple of log points:
I can see the LoginOptions is used and set in the agent context using the OAuth component.
But then once I start the login process the LoginOptions is back to the default value.

There is something clearly happening somewhere that cleans the LoginOptions because the audience and the scopes are conserved which are set at the same place are conserved:

<OAuth2 {config}
                scopes={vec!["openid".into(),"email".into(),"offline_access".into(),"api:call".into()]}
                audience={"http://localhost:8081/api"}
                options={login_options}>
                <Content/>
</OAuth2>

[ctron]

Weird indeed. But I have no idea what's going on. And you seem to have a reproducer at hand :)

[AlexandreRoba]

I've found this article that describe the need for anyone else reading the issue https://community.auth0.com/t/how-do-i-set-up-a-dynamic-allowed-callback-url/60268

@ctron I'm going to investigate a little further but I'm not even sure I will be able to capture and store the protected ressource url with the yew-oauth2 API before starting the login process. I'm wondering if I would not be better building my own custom oauth agent for auth0. I need to have it working now. :( thanks for the help you provided.

[AlexandreRoba]

@ctron Do you know why is LoginOption passed as parameters on the start_login?

  fn start_login(&mut self, options: LoginOptions) -> Result<(), OAuth2Error> {
        let client = self.client.as_ref().ok_or(OAuth2Error::NotInitialized)?;
        let config = self.config.as_ref().ok_or(OAuth2Error::NotInitialized)?;
        log::info!("start_login config are: {:?}", self.config);
        let redirect_url = match options.redirect_url {
            Some(redirect_url) => redirect_url,
            None => Self::current_url().map_err(OAuth2Error::StartLogin)?,
        };

Cause LoginOptions is an attribute of the config and is set there. I mean InnerConfig has an attributes option which contains the proper LoginOption value....

[ctron]

IIRC the original ideas was to allow one to manually start a login process (e.g. from your own component) with some additional options.

[ctron]

@ctron I'm going to investigate a little further but I'm not even sure I will be able to capture and store the protected ressource url with the yew-oauth2 API before starting the login process.

In the code I linked earlier, you will find 3 variables which are stored in the session store. I would suggest to add that information there. Then check the corresponding section where those variables are read again, and I you find our value stored, apply it.

I'm wondering if I would not be better building my own custom oauth agent for auth0. I need to have it working now. :(

I you believe that to the faster, that might be your better approach then. But from what I see, it should just be a few changes. But I also can't do that for you, as I don't have your environment set up, and also don't have the time to invest into that issue right now.

[kate-shine]

Thanks for dealing with this :) I'm facing the same issue with app using Microsoft Entra as IDP. If you need any testing or help, please let me know

[ctron]

Ok, I dug a bit into this, the reason for this is that the Redirect component calls start_login with default options. And when evaluating the agent doesn't take into consideration the "agent configured" login options.

Good news, this should be an easy fix.