Web 中的多个 JWT 授权令牌 API
Multiple JWT authorization token in Web API
我有一个使用 .Net Core 5 开发的 Web API 应用程序,我在其中使用 OIDC 2 实现了授权,因此使用了 JWT 不记名令牌。
现在我需要将此应用程序置于企业 API 网关之后,该网关充当代理,需要额外授权。
因此,请求应该有两个授权令牌,一个用于 API 网关,另一个用于应用程序本身。
网关管理员告诉我修改我的代码以处理如下请求:
curl -X GET "https://api-gateway.some-domain.org/my-application/some-endpoint"
-H "accept: application/json"
-H "MyApp-Authorization: Bearer JGVFISOODISJ..."
-H "Authorization: Bearer FVJIDOSJFMDSIO..."
我从管理员的回复中了解到,我应该修改我的应用程序中身份验证的配置方式,也许在启动文件中。
目前我是这样配置的:
public void ConfigureServices(IServiceCollection services)
{
//...
//Add ASP.NET Core Identity Services
services.AddIdentity<IdentityUser, IdentityRole>()
.AddEntityFrameworkStores<RPToolDBContext>()
.AddSignInManager<SignInManager<IdentityUser>>();
var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(appSettings.Secret));
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(opt =>
{
opt.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,
IssuerSigningKey = key,
ValidateAudience = false,
ValidateIssuer = false,
ValidateLifetime = true,
ClockSkew = TimeSpan.Zero
};
})
.AddAzureAdBearer(options => Configuration.Bind("AzureAd", options));
//...
}
修改属性名需要修改什么?
显然,我想我还需要更改 front-end 中的代码,它是使用 MSAL 库在 REACT 中开发的,以便使用新的 header...
如果它像这样工作,从良好的安全性和简单的代码标准的角度来看,这种模式可能是好的:
以不可读的格式向 Web 和移动客户端颁发机密访问令牌,以便不会向他们泄露任何敏感数据
APIs 接收包含声明和范围的 JWT,然后使用它们进行授权,包括所需的所有用户上下文
当客户端调用 API 时,消息通过网关路由,网关将机密令牌交换为 JWT
行业标准
在我的公司,我们称之为 The Phantom Token Pattern。值得一看的是您是否可以朝这个方向引导事情 - 例如,如果您与一位建筑师合作,请将我的回答转发给一位建筑师。
您的 API 不必使用 2 种类型的令牌或非标准 header 值,因为这将意味着安全库无法工作。
自定义验证器
作为最后的手段,您可以自定义 .Net 并以不同方式检索令牌。一些 sample code of mine 展示了如何自定义 .Net 堆栈,但仅用于学习目的。最好保持您的安全代码简单和标准。
我有一个使用 .Net Core 5 开发的 Web API 应用程序,我在其中使用 OIDC 2 实现了授权,因此使用了 JWT 不记名令牌。
现在我需要将此应用程序置于企业 API 网关之后,该网关充当代理,需要额外授权。 因此,请求应该有两个授权令牌,一个用于 API 网关,另一个用于应用程序本身。
网关管理员告诉我修改我的代码以处理如下请求:
curl -X GET "https://api-gateway.some-domain.org/my-application/some-endpoint"
-H "accept: application/json"
-H "MyApp-Authorization: Bearer JGVFISOODISJ..."
-H "Authorization: Bearer FVJIDOSJFMDSIO..."
我从管理员的回复中了解到,我应该修改我的应用程序中身份验证的配置方式,也许在启动文件中。
目前我是这样配置的:
public void ConfigureServices(IServiceCollection services)
{
//...
//Add ASP.NET Core Identity Services
services.AddIdentity<IdentityUser, IdentityRole>()
.AddEntityFrameworkStores<RPToolDBContext>()
.AddSignInManager<SignInManager<IdentityUser>>();
var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(appSettings.Secret));
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(opt =>
{
opt.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,
IssuerSigningKey = key,
ValidateAudience = false,
ValidateIssuer = false,
ValidateLifetime = true,
ClockSkew = TimeSpan.Zero
};
})
.AddAzureAdBearer(options => Configuration.Bind("AzureAd", options));
//...
}
修改属性名需要修改什么?
显然,我想我还需要更改 front-end 中的代码,它是使用 MSAL 库在 REACT 中开发的,以便使用新的 header...
如果它像这样工作,从良好的安全性和简单的代码标准的角度来看,这种模式可能是好的:
以不可读的格式向 Web 和移动客户端颁发机密访问令牌,以便不会向他们泄露任何敏感数据
APIs 接收包含声明和范围的 JWT,然后使用它们进行授权,包括所需的所有用户上下文
当客户端调用 API 时,消息通过网关路由,网关将机密令牌交换为 JWT
行业标准
在我的公司,我们称之为 The Phantom Token Pattern。值得一看的是您是否可以朝这个方向引导事情 - 例如,如果您与一位建筑师合作,请将我的回答转发给一位建筑师。
您的 API 不必使用 2 种类型的令牌或非标准 header 值,因为这将意味着安全库无法工作。
自定义验证器
作为最后的手段,您可以自定义 .Net 并以不同方式检索令牌。一些 sample code of mine 展示了如何自定义 .Net 堆栈,但仅用于学习目的。最好保持您的安全代码简单和标准。