Closed billcunnien closed 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?
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?
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.
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.
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/
All set on this issue @billcunnien?
I think so ... thanks!
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!