问题描述
带有ASP.NET Identity 3.0的ASP.NET Core 5,我同时使用网页和api.我正在使用OpenIddict发出JWT令牌并进行身份验证.我的代码如下:
X509Certificate2 c = new X509Certificate2(@"tokensign.p12", "MyCertificatePassword");
services.AddOpenIddict<WebUser, IdentityRole<int>, WebDbContext, int>()
.EnableTokenEndpoint("/api/customauth/login")
.AllowPasswordFlow()
.UseJsonWebTokens()
.AddSigningCertificate(c);
如果禁用UseJsonWebTokens(),则可以生成令牌并成功授权.但是,我不确定我的证书是否正在验证返回的令牌.
当启用UseJsonWebTokens时,我可以在此端点发出JWT令牌.但是,我无法验证任何请求!
我在应用程序配置中使用以下代码:
app.UseJwtBearerAuthentication(new JwtBearerOptions
{
AutomaticAuthenticate = true,
AutomaticChallenge = true,
RequireHttpsMetadata = false,
Authority = "http://localhost:60000/",
Audience = "http://localhost:60000/",
});
app.UseOAuthValidation();
app.UseIdentity();
app.UseOpenIddict();
app.UseMvcWithDefaultRoute();
- 如何强制执行要使用我的证书进行验证的请求,以确保JWT令牌不被篡改.
- 考虑到如果我不使用JWT,我将获得成功的授权,哪些设置将允许对JWT令牌进行验证和授权?
在ASOS(OpenIddict之后的OpenID Connect服务器框架)中,有两种不同的内置序列化机制可以创建和保护令牌:
- 使用IdentityModel (由Microsoft开发的库)并生成可由第三方验证的标准令牌的人:
身份令牌(按定义是JWT)始终使用此过程创建,您可以调用UseJsonWebTokens()
强制OpenIddict发出使用相同序列化过程的访问令牌.
调用AddSigningCertificate()
时指定的证书始终用于对这些令牌进行签名.
- 使用ASP.NET Core数据保护堆栈的人(也是Microsoft开发的):
此堆栈专门生成专有"令牌,这些令牌不打算由第三方读取或验证,因为令牌格式不是标准的,并且必须依赖于对称签名和加密. /p>
这是我们用于授权代码和刷新令牌的机制,仅供OpenIddict本身使用.使用默认令牌格式时,它也用于访问令牌.
在这种情况下,将不使用您在调用AddSigningCertificate()
时指定的证书.
相反,这些令牌始终由数据保护堆栈使用Authenticated Encryption
算法(默认情况下,具有HMACSHA256的AES-256-CBC)进行加密,该算法可提供真实性,完整性和机密性.为此,数据保护堆栈从存储在密钥环中的一个主密钥中派生出2个密钥(一个用于加密,一个用于验证).
要回答这些问题,如果启用了日志记录并共享了跟踪,将会有所帮助.
ASP.NET Core 5 with ASP.NET Identity 3.0, I'm using both web pages and apis. I am using OpenIddict to issue a JWT token and to authenticate. My code looks as such:
X509Certificate2 c = new X509Certificate2(@"tokensign.p12", "MyCertificatePassword");
services.AddOpenIddict<WebUser, IdentityRole<int>, WebDbContext, int>()
.EnableTokenEndpoint("/api/customauth/login")
.AllowPasswordFlow()
.UseJsonWebTokens()
.AddSigningCertificate(c);
If I disable UseJsonWebTokens(), I can generate a token and authorise successfully. However, I am not sure that my certificate is validating the returned tokens.
And when enable UseJsonWebTokens, I am able to issue a JWT token at this end point. However, I can't authenticate any request!
I am using the following code in the app configuration:
app.UseJwtBearerAuthentication(new JwtBearerOptions
{
AutomaticAuthenticate = true,
AutomaticChallenge = true,
RequireHttpsMetadata = false,
Authority = "http://localhost:60000/",
Audience = "http://localhost:60000/",
});
app.UseOAuthValidation();
app.UseIdentity();
app.UseOpenIddict();
app.UseMvcWithDefaultRoute();
- How can I enforce the request to be validated with my certificate to make sure the JWT token is not tampered with.
- What are the correct settings that will allow validation and authorisation of my JWT token, given that if I am not using JWT, I am getting authorised successfully.
In ASOS (the OpenID Connect server framework behind OpenIddict), there are 2 different built-in serialization mechanisms to create and protect tokens:
- One that uses IdentityModel (a library developed by Microsoft) and produces standard tokens verifiable by third parties:
Identity tokens (JWT by definition) are always created using this process and you can call UseJsonWebTokens()
to force OpenIddict to issue access tokens that use the same serialization process.
The certificate you specify when calling AddSigningCertificate()
is always used to sign these tokens.
- One that uses the ASP.NET Core Data Protection stack (also developed by Microsoft):
This stack exclusively produces "proprietary" tokens that are not meant to be read or verified by a third-party, as the token format is not standard and necessarily relies on symmetric signing and encryption.
It's the mechanism we use for authorization codes and refresh tokens, that are only meant to be consumed by OpenIddict itself. It's also used for access tokens when you use the default token format.
In this case, the certificate you specify when calling AddSigningCertificate()
is not used.
Instead, these tokens are always encrypted by the Data Protection stack using an Authenticated Encryption
algorithm (by default, AES-256-CBC with HMACSHA256), that provides authenticity, integrity and confidentiality. For that, 2 keys (one for encryption, one for validation) are derived by the Data Protection stack from one of the master keys stored in the key ring.
To answer these questions, it would help if you enabled logging and shared your traces.
这篇关于通过JWT令牌授权的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!