自己发行 JWT 令牌与使用 IdentityServer4(OIDC) 进行 Web API [英] Issuing JWT token myself versus using IdentityServer4(OIDC) for Web API

问题描述

我真正想要实施以保护我的 Web API:

• 登录
• 注销(使令牌无效?)
• 没有同意屏幕(只想为我自己提供 API)，身份验证在我的原生桌面、移动、网络应用程序的后台进行(无重定向)
• 记住我功能(刷新令牌?)

谁能帮我清除一下 OIDC/OAuth2 的模糊画面?即给我一些我自己的方式的缺点(实现我自己的流程)和使用 OIDC 代替我自己的流程的优势.

它将使我以后免于做什么(例如在客户端)，什么不会.尤其是，使用 OIDC 等标准流程开始每个项目是否合适?将来它会以某种方式使我受益吗?

解决方案

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

忘记 Oidc，Identity Server 4 就是关于身份验证的:谁是用户"?考虑谷歌登录.当用户第一次登录时，应用程序不认识该用户，它只知道 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屋！