我自己发行JWT令牌，而不是将IdentityServer4(OIDC)用于Web API [英] Issuing JWT token myself versus using IdentityServer4(OIDC) for Web API

问题描述

https://identityserver4.readthedocs.io/en/release/intro /support.html

我目前在自己的Web api中使用JwtSecurityToken自己发行令牌，并且我使用标准的ASP.NET Core中间件调用AddJwtBearer来验证令牌.效果很好.

与上述方法相比，使用OpenID Connect(通过IdentityServer4)有什么优势?如何回答自己的问题我需要OpenID Connect吗?"

根据我对OpenID Connect的基本了解，它用于允许第三方访问您的API.但是，我为自己而不是为第三方创建API，而且我不知道为什么我应该选择IdentityServer/OpenIddict而不是我的简单方法.

我读到，如果我想要单点登录，则应使用此功能，但JWT本身并不绑定到任何特定域，并且我可以将单点登录与纯JWT一起使用(它们是自包含的). /p>

我了解它实现了某种发行令牌的标准. (协议).如果我希望向第三方公开一些API，可能会很好.但是对于内部API?值得使用吗?

这是我当前的身份验证流程(来自解决方案

无论如何，您都将实现OAuth2.将Oidc视为OAuth2的扩展.要记住的最重要的事情是关注点分离.

忘记Oidc，Identity Server 4完全是关于身份验证的:用户是谁"?考虑使用Google登录名.用户首次登录时，应用程序不知道该用户，只知道Google.

授权发生在不同的级别，并不是IdentityServer真正关心的问题.为此，您可以查看 PolicyServer .

因此，您需要将用户数据库与应用程序数据库分开.这并不意味着您需要另一个数据库，只是不要混合上下文.如果您有一个从业务环境"到例如在身份上下文"中的用户表中，那么最终您将遇到问题.

在您的设置中，您的Web API既是资源也是身份提供者.这意味着您创建的每个新的Web API必须同时实现为资源和身份提供者.为了可维护性，您可以创建一个单独的Web api充当身份提供者，而该Web api只是一种资源.只要所有应用程序都可以读取令牌，就可以实施类似的操作.

前面同样重要.为什么前端与用户有任何关系?它需要做的就是传递令牌以使用户获得授权.如果使用IdentityServer，则应用程序会与它联系以验证用户并接收令牌.它对凭据一无所知.这样更安全.客户端应用可能会受到威胁.凭据可以被拦截.

具有单个关注的单个应用程序使事情更易于维护.使用IdentityServer时，无需编写代码即可添加新资源非常容易.只需添加配置.它还允许您将来添加当前不需要的其他流.另外，同意屏幕是可选的.

好处是您可以实施SSO，在您的设置中，如果不是不可能的话，可能会更困难.

因此，您不必使用IdentityServer或Oidc.您的设置可能很好.但是，如果您有所建树，请牢记关注点分开.

https://identityserver4.readthedocs.io/en/release/intro/support.html

I currently issue tokens myself in my web api with JwtSecurityToken and I use standard ASP.NET Core middleware calling AddJwtBearer to verify the tokens. It works fine.

What advantage will give me using OpenID Connect (through IdentityServer4) over the approach described above? How to answer myself question "Do I need OpenID Connect?"

From my basic understanding about OpenID Connect, it is used to allow third parties to access your API. But I make API for myself and not for third parties and I don't know why should I favor IdentityServer/OpenIddict over my simple approach.

I read that if I want Single sign-on I should use this, but JWTs itself aren't bound to any specific domain and I can use single sign-on with just pure JWTs(they're self-contained)

I understand it implements some kind of standard for issuing tokens. (protocol). It might be good if I ever wish to expose some API to third parties. But for internal APIs? Is it worth using it?

This is my current auth flow (from https://jonhilton.net/2017/10/11/secure-your-asp.net-core-2.0-api-part-1---issuing-a-jwt/)

What I really want to implement to secure my Web API:

• Login
• Logout (invalidate token?)
• No consent screen (want to have API only for myself), auth happens in the background in my native desktop, mobile, web app (no redirection)
• Remember me feature (refresh tokens?)

Could someone clear out the fuzzy picture of OIDC/OAuth2 for me? i.e. give me some disadvantages going my own way (implementing my own flow) and advantages of using OIDC in place of my own flow.

What will it save me from doing later on (on the client-side for example), and what will not. And most particularly, is it good to start every project using standard flows like OIDC? Will it somehow benefit me in the future?

解决方案

In any case you will implement OAuth2. Think of Oidc as an extension of OAuth2. The most important thing to keep in mind is seperation of concerns.

Forget Oidc, Identity Server 4 is all about authentication: "who is the user"? Consider Google login. When a user logs in for the first time, the application doesn't know the user, it only knows that Google does.

Authorization takes place on a different level and isn't really a concern of IdentityServer. For that you could take a look at PolicyServer.

So you'll need to keep the user database seperated from the application database. This doesn't mean you need another database, just don't mix contexts. If you have a relation from the "business context" to e.g. the user table in the "Identity context" then you are going to have a problem eventually.

In your setup your web api is both the resource and the identity provider. This means that every new web api you create has to be implemented as both resource and identity provider. For maintainability you could create a seperate web api that acts as an identity provider, while the web api is a resource only. You can implement something like that as long as all apps can read the token.

The same counts for the front. Why should the front have anything to do with the user? All it needs to do is pass the token in order to get the user authorized. In case of IdentityServer, the app contacts it to verify the user and receives a token. It knows nothing about credentials. This is more secure. The client app can be compromised. The credentials can be intercepted.

Having single apps with a specific concern makes things more maintainable. And it is quite easy to add a new resource without having to code when you use IdentityServer. Just add the configuration. It also allows you to add other flows in the future that are not needed at this time. And as a side note, the consent screen is optional.

The bonus is that you can implement SSO, where in your setup that could be harder, if not impossible.

So you don't have to use IdentityServer, nor Oidc. Your setup may be just fine. But if you build something, keep seperation of concerns in mind.

这篇关于我自己发行JWT令牌，而不是将IdentityServer4(OIDC)用于Web API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！