Openiddict-core: token enpoint started to return 404

[spacedsweden]

So trying the with invalid credentials and i get all the good error codes, but submitting good credentials
IIS return 404 right after the seclect application. Strange thing is that it worked like a charm

Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request starting HTTP/1.1 POST http://localhost:3174/connect2/token application/x-www-form-urlencoded 83
Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommandBuilderFactory:Information: Executed DbCommand (9ms) [Parameters=[@__identifier_0='?' (Size = 450)], CommandType='Text', CommandTimeout='30']
SELECT TOP(2) [application].[Id], [application].[ClientId], [application].[ClientSecret], [application].[DisplayName], [application].[LogoutRedirectUri], [application].[RedirectUri], [application].[Type]
FROM [OpenIddictApplications] AS [application]
WHERE [application].[ClientId] = @__identifier_0
Microsoft.AspNetCore.Hosting.Internal.WebHost:Information: Request finished in 71.801ms 404 

To be honest i probably f*ed up something since it did work, but i have no idea after an hour of look in to this. Let me know if you can help and you need any more info.

[spacedsweden]

Downgrading to 0419 solved it. so prop something wrong with the brand new one

[vip30]

I have same issue too and I just think what am I doing wrong as it work as expected before
Thanks for the comment.

[kevinchalet]

Downgrading to 0419 solved it. so prop something wrong with the brand new one

Nope, that's a deliberate design change introduced in the last version. As explained in the README, you must know provide your own token endpoint action to handle token requests.

[mkontula]

A deliberate braking change that requires "a Swedish 99.9%" of all users of token authentication based on client creds to write mostly unnecessary broilerplate code. Are you serious? :-1:

[kevinchalet]

@mkontula this change was introduced to give you more flexibility (e.g you can now easily add more claims or set scopes based on your app policy). It also makes the token endpoint consistent with how Identity and its AccountController work in general. It's less magic.

[mkontula]

@PinpointTownes I totally agree, but a total removal? Why not keep the old functionality and make it possible to write your own? Or make it a new configuration option like: .EnableOldMonstrouslyMagicDefaultTokenEndpoint("path_goes_here") ? It's alpha2, yes, we understand but still the change was a bit rough? It's yours and usage is voluntary, but still.

[vip30]

I agree with mkontula. It is better that If you keep the old method and support for overriding.
It make me just so scary that it give out a 404 whole day and I don't know why (Sorry, I haven't seen the update log on these days)
But finally , I think this added feature is cool.

[ruben0909]

I agree with @mkontula and thank you for your awesome work @PinpointTownes

[vip30]

@PinpointTownes
Sorry, I would like to ask is there any sample code for other flow? (like refresh token)

[armartinez]

Yeah I would also appreciate an example for the code flow, I tried the one in the server sample and it didn't work for me, I'm sticking with 0419 for the moment

[kevinchalet]

@vip30 @armartinez grant_type=authorization_code and grant_type=refresh_token token requests are still managed by OpenIddict itself. It hasn't changed and there's no plan to change it.

[armartinez]

@PinpointTownes I had to rollback to 0419 for it to work with the authorization code flow, it returns a 404 when trying to GET /connect/authorize?request_id=...

[kevinchalet]

Have you created your authorization endpoint? https://github.com/openiddict/openiddict-core/pull/190 had introduced a default logic but it was rolled back last weekend.

[armartinez]

Sorry I didn't read you correcty, I thought we didn't need that for the code flow but you meant only the token endpoint. I tried to implement the same endpoint as the MVC Server example and it didn't work for me, so for now I'm using the old one.

[kevinchalet]

@armartinez does the MVC server sample work for you? I just tried it and it behaves as expected.

[armartinez]

@PinpointTownes No it doesn't work for me but my implementation is different since my server behaves like and API not an MVC application like the sample, so there are differences that I need to take into account. One question, do I still need to add the call EnableAuthorizationEndpoint("/connect/authorize") even if I implemented my own endpoint?

[kevinchalet]

One question, do I still need to add the call EnableAuthorizationEndpoint("/connect/authorize") even if I implemented my own endpoint?

Sure. If you don't, the authorization endpoint won't be enabled.

[piotrek-k]

@PinpointTownes there is some problem with this line of your code (Exchange() method):

var identity = await _userManager.CreateIdentityAsync(user, request.GetScopes());

'UserManager' does not contain a definition for 'CreateIdentityAsync' and no extension method 'CreateIdentityAsync' accepting a first argument of type 'UserManager' could be found (are you missing a using directive or an assembly reference?)

Fixed. I was using UserManager instead of OpenIddictUserManager

BTW: wow, I wasted a few hours figuring out why my token endpoint returns 404. You should definitely throw some exceptions when your library is used wrong way. But this change was definitely necessary, thanks for that.

[kevinchalet]

@piotrek-k _userManager is an OpenIddictUserManager<TUser> instance.

You should definitely throw some exceptions when your library is used wrong way.

It's hard in this case: once your app gets back flow control, it's nearly impossible to say if you've handled the token request.

[javico2609]

if you want the default behavior
download the OpenIddictMiddleware.cs here GitHub`

and create one Extensions method to include this middleware into pipeline

``` c#
public static class CustomOpenIddictExtensions
{
public static IApplicationBuilder UseAsDefaultOpenIdDict(this IApplicationBuilder builder)
where TUser : OpenIddictUser
{
return builder.UseMiddleware TUser,
OpenIddictApplication,
OpenIddictAuthorization,
OpenIddictScope,
OpenIddictToken>>();
}
}

and call into Startup.cs always after app.UseOpenIddict();

``` c#
app.UseAsDefaultOpenIdDict<ApplicationUser>();

[kevinchalet]

@javico2609 there was a reason if OpenIddictMiddleware was removed: it didn't work as expected :smile:

The recommended approach is to have a custom controller action, similarly to what's required for interactive flows.

[javico2609]

ok, thx @PinpointTownes

[t3hmun]

@PinpointTownes, can you add a warning in the README sample to say that it is missing _signInManager.CanSignInAsync(user) (essential for accounts requiring email/text verification).

When upgrading from the old version of the code my brain had assumed that was done by magic, luckily I had written a test.

I believe this warning applies to the samples posted in this issue too.

[kevinchalet]

@t3hmun thanks for the tip. For clarity, I removed the abbreviated sample from the README: https://github.com/openiddict/openiddict-core/commit/44ee0f6ceaf21936b7f938e026ed0889bf1b5374

The "complete" sample has the right check:
https://github.com/openiddict/openiddict-core/blob/dev/samples/Mvc.Server/Controllers/AuthorizationController.cs#L124-L130