DuendeSoftware / Support

Support for Duende Software products
20 stars 0 forks source link

Invalid Redirect_URI #128

Closed billcunnien closed 2 years ago

billcunnien commented 2 years ago

Which version of Duende IdentityServer are you using? v6

Which version of .NET are you using? .NET Core 6

I am trying to test the authorization code workflow. As I understand, the user will be redirected from the third-party application to the IS where the user will authenticate and accept the requested access. Then, the IS will send the user back to the originating third-party application with a code in the URL (to the redirect url?). The third-party application will be able to use the code and make a POST request to the IS endpoint to exchange to the code for the tokens (access, refresh, etc.). Then the third-party application will make calls to the API with the access token.

If I use anything other than "https://localhost:7003/signin-oidc" as an entry in the client RedirectUris, then I get "invalid redirect_uri" when the third-party application attempts to authenticate (hits the IS account/login page). If I do use that URI, then the user can login properly and is sent back to the application. The resulting properties of the AuthenticateResult object of the HttpContext does indeed house all of the tokens already. There seems to be no need to make any exchange.

I am a bit confused. Hope you can clear things up for me. Thanks!

brockallen commented 2 years ago

If you're using ASP.NET Core, then their "AddOpenIdConnect" handler does all that work. It's what listens on the ~/signin-oidc endpoint for the result, and inside it's implementation it does the code exchange and session/cookie creation in the client app.

Is there something specific you're trying to do or change?

billcunnien commented 2 years ago

I was just trying to pretend I am a third-party application and see how the token exchange would work. Since I indeed have AddOpenIdConnect setup in the test web application, that explains the behavior. Is there a setting to do this without the default plumbing?

brockallen commented 2 years ago

There's a callback path on the OIDC options if you want to change that. There are a lot of other options (and events/callbacks) too that allow you to get involved and control things.

billcunnien commented 2 years ago

Rather than AddOpenIdConnect, I tried this:

builder.Services.AddAuthentication()
            .AddOAuth("oauth", options =>
            {
                options.ClientId = "test";
                options.ClientSecret = "secret";
                options.CallbackPath = new PathString("/auth");                
                options.AuthorizationEndpoint = "https://localhost:5001/connect/authorize";
                options.TokenEndpoint = "https://localhost:5001/connect/token";
                options.UserInformationEndpoint = "https://localhost:5001/connect/userinfo";
                options.Scope.Clear();
                options.Scope.Add("openid");
                options.Scope.Add("api");
                options.Scope.Add("offline_access");
            });

But, this does not want to redirect to the IS, at all. Oddly, the resulting authentication URL is "https://localhost:7003/Account/Login?ReturnUrl=%2F" (7003 is the test web application). The account/login path exists on the IS. Naturally, this is a 404 for the web app.

Eventually, I will stumble on the right combination of options and configurations between IS and the web app. Very time consuming. Just when I think I have a handle on the actual process and take a step forward, I stumble two steps back.

brockallen commented 2 years ago

But your app is using OIDC, not just OAuth. This is the wrong handler for what you need/want, I think.

As for the redirect - if you look in your browser's dev tools and look at the network requests you will see the authorize endpoint, but then the login page. See this for more info: https://docs.duendesoftware.com/identityserver/v6/fundamentals/users/

brockallen commented 2 years ago

All set on this issue @billcunnien?

billcunnien commented 2 years ago

I think so ... thanks!