Add refresh token support to BearerTokenHandler

[halter73]

• Integrate with identity to check security stamp and refresh user from store

Fixes #47228

[kevinchalet]

This property seems really specific to the "API endpoints" stuff and will likely be confusing for users of different authentication handlers that also use AuthenticationProperties. Is a public API really needed?

[halter73]

It's specific to the new BearerTokenHandler, but there are other AuthenticationProperties properties that don't apply to every hander. AFAIK IsPersistent and AllowRefresh are both only used by CookieAuthenticationHandler. I'd be fine with hiding ".refreshToken" in some constant if we could find a place it makes sense. Otherwise, I think this is alright.

I'm more worried about AddBearerToken getting confused with AddJwtBearer. I still think we might want to go with AddIdentityBearer like I originally proposed in #47227 rather than AddBearerToken so people don't confuse it with the AddJwtBearer. But you can technically use it without Identity, which is why we went with the current name in API review.

I welcome less confusing naming suggestions for AddBearerToken that's not Identity specific too. AddOpaqueBearer maybe?

[kevinchalet]

It's specific to the new BearerTokenHandler, but there are other AuthenticationProperties properties that don't apply to every hander. AFAIK IsPersistent and AllowRefresh are both only used by CookieAuthenticationHandler.

This problematic design was inherited from Katana and recent developments deliberately avoided adding new properties to the base AuthenticationProperties to avoid that. See https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/OAuth/src/OAuthChallengeProperties.cs and https://github.com/dotnet/aspnetcore/blob/main/src/Security/Authentication/Google/src/GoogleChallengeProperties.cs for examples of specialized AuthenticationProperties sub-classes. I'm not sure it's really worth having public properties, but if you wanted to, it's likely the design you'd want to adopt.

Regarding the name of the extensions, I don't have any particular opinion as I'm sadly unlikely to use this feature. If these "Identity API endpoints" were usable with existing projects like IdSrv or OpenIddict as I unsuccessfully suggested here, that would make them much more appealing, but heh 🤷🏻

[davidfowl]

@kevinchalet Do these current endpoints stop us from adding the ones that you think would be valuable? Also, did you write up any more details with what you think you would need?

[kevinchalet]

@davidfowl well, despite being part of the Core Identity package, these "Identity API endpoints" aren't meant to be used without your custom "OAuth 2.0-like bearer token generation handler", AFAICT. Yet, these endpoints (and the future ones you plan to add like the password change/reset endpoints) would be useful to users of existing OAuth 2.0/OIDC solutions like OpenIddict.

Also, did you write up any more details with what you think you would need?

Here's a quick list of things that would be nice:

• Having a clear separation between the token generation/validation handler and the Identity management API endpoints (e.g the /register endpoint isn't authenticated so it would be directly usable in an OpenIddict app without forcing the dev' to use your custom token generation handler).

• It would make more sense to have these new things in a dedicated Identity package so that the .Core Identity package doesn't have to reference your custom token generation handler (many OpenIddict users use Identity, but they don't need/want to reference Microsoft.AspNetCore.Authentication.BearerToken).

• For bonus points, it wouldn't be hard to make the underlying authentication scheme configurable for the token generation, so that the /login endpoint could be used with a different token server backend (let's say OpenIddict 😄)

[davidfowl]

@kevinchalet Can you file a design proposal issue? If it's not too disruptive to what we're trying to accomplish with these endpoints then it seems reasonable. Otherwise, we'll punt until .NET 9.