Closed nbelley closed 2 years ago
Thanks for sponsoring the project!
After that, there is a redirect to the connect/token method but my TheManager app redirects to login (seems the user is not really logued in? or something else?
This part sounds weird to me: the token endpoint is not an interactive endpoint and works pretty much like an API endpoint so you're not supposed to make any redirection at this stage.
Could you please capture a Fiddler trace? This would help pinpoint where the issue is.
Thanks for sponsoring the project!
After that, there is a redirect to the connect/token method but my TheManager app redirects to login (seems the user is not really logued in? or something else?
This part sounds weird to me: the token endpoint is not an interactive endpoint and works pretty much like an API endpoint so you're not supposed to make any redirection at this stage.
Could you please capture a Fiddler trace? This would help pinpoint where the issue is.
Thanks for your answer! I'm not sure what's supposed to happen after the login on the server, should the token endpoint be called there or the process is already over?
Anyway, I have a fiddler trace, where can I send it to you?
Thanks for your answer! I'm not sure what's supposed to happen after the login on the server, should the token endpoint be called there or the process is already over?
Yeah, the token endpoint is expected to be called using an HTTP client to redeem the authorization code and get an access token. Assuming you're using a recent version of the OWIN OIDC middleware, this should be supported and automatically done for you under the hood.
Anyway, I have a fiddler trace, where can I send it to you?
You can drag&drop it here or send it privately to my email address (it's indicated in my profile).
If you can also join client and server logs, don't hesitate.
The traces indicate that the call to /connect/token resulted in a redirection response to a login page. Since it's not a valid JSON response, the OIDC middleware throws an exception to abort the callback process.
Do you have some custom code somewhere that forces all calls to be authenticated or something similar? Calls to /connect/token are unauthenticated by nature so this path must be excluded from any custom policy.
I'm a bit at a loss there... I mean, I do have code that can result in a redirect to login, if the requested route is secured, but I have done nothing special for /connect/token.
I've tried to comment everything that requires an authorisation in the app... nothing works.
It seems that it's related to my cookie configuration in my auth server.
I changed
AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Active,
To
AuthenticationMode = Microsoft.Owin.Security.AuthenticationMode.Passive,
And I now have a new error, at least I came back to my other app to the signin-oidc callback
Ah, you're unfortunately hitting an annoying design flaw in Katana: authentication middleware are known to be very greedy and catch 401 responses when using Active
even when they are not supposed to. It's one of the annoying things we fixed when revamping ASP.NET Core's authentication stack.
In this specific case OpenIddict detects you're using invalid credentials and returns a 401 response as required by the OAuth 2.0 specification. Yet, the cookies middleware detects a 401 response is being returned and starts doing its redirection thing, which ends up overriding what OpenIddict did.
I'll consider introducing a workaround in a future version to avoid that. In the meantime, you can add one in your own app using OpenIddict's event model:
services.AddOpenIddict()
.AddServer(options =>
{
options.AddEventHandler<ApplyTokenResponseContext>(builder =>
builder.UseInlineHandler(context =>
{
var request = context.Transaction.GetOwinRequest();
if (request.Context.Response.StatusCode is 401)
{
// Attach an explicit challenge pointing to a non-existing authentication middleware
// to prevent the cookies middleware from overriding OpenIddict 401 responses.
request.Context.Authentication.AuthenticationResponseChallenge =
new AuthenticationResponseChallenge(new[] { "Dummy" }, new());
}
return default;
})
.SetOrder(AttachHttpResponseCode<ApplyTokenResponseContext>.Descriptor.Order + 1));
});
Yes, ça marche | it works! 👍 With my old config.
Now, the only question is why the client is invalid? Pretty sure it was good, I'll check that a bit to see. I'm not crazy, the client app doesn't need to have any of the openiddict tables?
I'm not crazy, the client app doesn't need to have any of the openiddict tables?
Right, the client never accesses the server database. That said, you do need to have an entry in the applications table for that specific client. If you get this error, then it's likely either your client_id or your client_secret is/are invalid.
EDIT: nevermind, it works, but I'm not receiving my custom claims that are added in the server. In the client, I only have the claims from oauth, my custom claims arent there?
Now I'm stuck on the sign out, but as for the login, everything seems good, thanks for your help @kevinchalet
For the record, this was fixed in OpenIddict 4.0 preview1: https://kevinchalet.com/2022/06/22/openiddict-4-0-preview1-is-out/
For the record, this was fixed in OpenIddict 4.0 preview1: https://kevinchalet.com/2022/06/22/openiddict-4-0-preview1-is-out/
Thanks! Not sure I'm game to migrate to 4.0 right now! :)
Confirm you've already contributed to this project or that you sponsor it
Version
3.x
Question
Intro on our systems:
So, I based (copied lol) the samples Mortis.client on the ClientApp and Mortis.server on TheManager.
The flow seems to be working quite well, until the token:
I'm trying to implement the sample client server in my current MVC apps to use openiddict.
I have a client App, that I configured to the best of my knowledge the same way as the MvcClient app in the samples project (mortis.client).
This seems to work.
I have an authentication app, which is used to authenticate our users across multiple applications, I integrated the mortis.server example in it. But I'm pretty sure I missed some stuff, here is what happens:
The client app requests access to the server app, it works, the connect/authorize method is called in the AuthorizeController of the server app, then, it requests the login of the user first (if not loggued in). After that, connect/authorize is called again, logs signs in the user and builds the identity and it passes in the implicit consent type switch/case.
After that, there is a redirect to the connect/token method but my McvServer apps redirects to login (seems the user is not really logued in?)
What am I doing wrong?
This is my Client App setup
public void ConfigureAuth(IAppBuilder app) { IdentityModelEventSource.ShowPII = true;
}
The signin link is the same as in the sample app (a sign in view that challenges owin access)
This is TheManager app configuration:
This is the AuthorizeController: