自己发行 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.

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

在您的设置中，您的网络 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屋！