问题描述
我使用Visual Studio 2015年企业更新1和ASP.NET vNext RC1-UPDATE1发行和消费说明JWT令牌here.
I am using Visual Studio 2015 Enterprise Update 1 and ASP.NET vNext rc1-update1 to issue and consume JWT tokens as described here.
在我们的实现，我们要控制令牌终身验证。
In our implementation we want to control token lifetime validation.
我们尝试了几种方法，所有这些都不良的副作用。例如，在一个尝试，我们接手了TokenValidationParameters.TokenValidationParameters.LifetimeValidator事件中的配置的方法：
We tried several approaches, all of which had undesirable side effects. For example in one attempt we took over the TokenValidationParameters.TokenValidationParameters.LifetimeValidator event in the Configure method:
app.UseJwtBearerAuthentication
(
options =>
{
options.TokenValidationParameters = new TokenValidationParameters()
{
LifetimeValidator = (DateTime? notBefore, DateTime? expires, SecurityToken securityToken, TokenValidationParameters validationParameters) =>
{
// Pretend to do custom validation
return false;
}
};
}
);
这事件导致验证失败，因为我们想，但客户端收到500错误，而我们想返回400系列错误和小型有效载荷来代替。
That event causes validation to fail as we'd like but the client receives a 500 error whereas we would like to return a 400-series error and a small payload instead.
在另一种尝试，我们尝试TokenValidationParameters.Events的各种实现，比如在ValidatedToken事件检测要求，但发现我们无法prevent援引抛出异常的控制器动作短中间件这让我们回500错误的问题。
In another attempt we tried various implementations of TokenValidationParameters.Events, such as inspecting claims in the ValidatedToken event but found we were unable to prevent the middleware from invoking the controller action short of throwing an exception which got us back to the 500 error problem.
所以我的问题是：
-
什么是什么接管一生验证与OIDC的最佳实践？
What what is the best practices for taking over lifetime validation with OIDC?
我们能否迫使OIDC不包括像NBF令牌一定的寿命要求，因为我们不再需要它们了呢？
Can we force OIDC not to include certain lifetime claims in the token like "nbf" since we won't need them anyway?
推荐答案
编辑：此错误是固定在ASP.NET核心RC2。在这个答案中描述的解决方法是不再需要。
这是一个。可悲的是，不再适用在RC1 。
It's a known bug. Sadly, the workaround you could use in beta8 no longer works in RC1.
您唯一的选择就是写一个中间件捕捉异常prevent从返回500响应服务器。当然，它的丑陋，将有可能隐藏重要的例外，但它是唯一已知的解决方法，与RC1的作品。
Your only option is to write a middleware catching the exception to prevent the server from returning a 500 response. Of course, it's ugly and will potentially hide important exceptions, but it's the only known workaround that works with RC1.
下面是一个例子（确保JWT承载中间件之前进行注册）：
Here's an example (make sure to register it before the JWT bearer middleware):
app.Use(next => async context => {
try {
await next(context);
}
catch {
// If the headers have already been sent, you can't replace the status code.
// In this case, throw an exception to close the connection.
if (context.Response.HasStarted) {
throw;
}
context.Response.StatusCode = 401;
}
});
这篇关于定制验证寿命随着AspNet.Security.OpenIdConnect.Server（ASP.NET vNext）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！