前端和后端的JWT令牌策略 [英] JWT Token strategy for frontend and backend

问题描述

我在一个nodejs服务器中的emberjs和后端/服务器端的前端编写一个应用程序。我配置了emberjs，以便用户可以使用第三方Oauth（google，twitter，Facebook）进行登录/注册。我有一个后端，用于承载RESTful API的express nodejs服务器。

我没有DB连接到emberjs，我不认为我应该反正，因为它是严格的客户端代码。我正在计划使用JWT来在客户端和服务器端进行通信。当用户使用其oauth证书登录时，我将从提供程序中获取一个JSON对象，其中包含uid，name，login，access_token和其他详细信息。

我正在努力挑选如何处理用户注册的策略。由于它是OAuth，因此没有注册过程。所以流是如果用户不在我的数据库，创建它。我不支持电子邮件/密码验证。当用户首次登录OAuth提供商时，流量会是多少？ emberjs会在每个登录时向后台发送所有的详细信息，以便后端可以向db添加新用户？

我的JWT机构应该是什么？我在想，提供者提供了访问令牌。我可以想到的一个问题是，提供者特定的访问令牌可以改变。用户可以从提供商的站点撤销令牌，并使用emberjs重新注册。

如果使其更容易，我可以在任何其他JavaScript客户端框架中编写前端。

解决方案

如果我们谈论的不仅是工作，而且是安全的无状态身份验证，您将需要考虑适当的策略与访问和刷新令牌。

1. 访问令牌是提供对受保护资源的访问的令牌。
   Expiration 这可能会在约1小时内安装（取决于您的注意事项）。




2. 刷新令牌是一个特殊的令牌，应该用于生成额外的访问令牌，以防其已过期或用户会话已更新。显然，您需要使其长期存活（与访问令牌相比）并尽可能安全。
   到期日期 可能大约在〜10天甚至更多（也取决于您的注意事项）安装。

   / li>
   

FYI：由于刷新令牌长寿为了使它们真正安全，您可能希望将它们存储在数据库中（刷新令牌请求很少执行）。这样就可以说，即使你的刷新令牌被黑客入侵，有人重新生成了访问/刷新令牌，你当然会松开权限，但是你仍然可以登录系统，因为你知道登录/通过（如果你以后会使用它们）或只是通过任何社交网络登录。

---

存储这些令牌的位置

基本上有两个常见的地方：

1. HTML5网络存储（localStorage / sessionStorage）

去，但在同一时间有足够的风险。存储可通过同一域上的JavaScript代码访问。这意味着如果您有

---

关于 JWT 本身的几个字：

来自Auth0的人们真的很酷的 JWT调试器。
有2（有时3个）常见的索赔类型： public ， private （和 reserved ）。

JWT body（有效载荷，可以是任何你想要的）：

  {
名称：Dave Doe，
 isAdmin：true，
 providerToken：'...'//应单独验证
} 
  

有关 JWT 结构的更多信息，您会发现这里。

I'm writing an application with a front end in emberjs and backend/server-side in a nodejs server. I have emberjs configured so that a user can login/signup with an 3rd party Oauth (google, twitter, Facebook). I have a backend written in express nodejs server that hosts the RESTful APIs.

I do not have DB connected to emberjs and I don't think I should anyways since it's strictly client side code. I'm planning on using JWT for communicating between client side and server side. When a user logins with their oauth cred, I get a JSON object back from the provider with uid, name, login, access_token and other details.

I'm struggling with picking a strategy on how to handle user signup. There is no signup process since it's OAuth. So the flow is if the user is not in my db, create it. I do not support email/password authentication. What would be the flow when a user signs in with an OAuth provider for the first time? Should emberjs send all the details to the backend on every sign in so that backend can add new users to the db?

What should be part of my JWT body? I was thinking uid and provider supplied access token. One issue I can think of here is that provider specific access token can change. User can revoke the token from provider's site and signs up again with emberjs.

I'm open to writing the front-end in any other javascript client side framework if it makes it easier.

解决方案

If we're talking about not only working but also secure stateless authentication you will need to consider proper strategy with both access and refresh tokens.

1. Access token is a token which provides an access to a protected resource. Expiration here might be installed approximately in ~1 hour (depends on your considerations).

2. Refresh token is a special token which should be used to generate additional access token in case it was expired or user session has been updated. Obviously you need to make it long lived (in comparison with access token) and secure as much as possible. Expiration here might be installed approximately in ~10 days or even more (also depends on your considerations).

FYI: Since refresh tokens are long lived, to make them really secure you might want to store them in your database (refresh token requests are performed rarely). In this way, let's say, even if your refresh token was hacked somehow and someone regenerated access/refresh tokens, of course you will loose permissions, but then you still can login to the system, since you know login/pass (in case you will use them later) or just by signing in via any social network.

---

Where to store these tokens?

There are basically 2 common places:

1. HTML5 Web Storage (localStorage/sessionStorage)

Good to go, but in the same time risky enough. Storage is accessible via javascript code on the same domain. That means in case you've got XSS, your tokens might be hacked. So by choosing this method you must take care and encode/escape all untrusted data. And even if you did it, I'm pretty sure you use some bunch of 3rd-party client-side modules and there is no guarantee any of them has some malicious code.

Also Web Storage does not enforce any secure standards during transfer. So you need to be sure JWT is sent over HTTPS and never HTTP.

2. Cookies

With specific HttpOnly option cookies are not accessible via javascript and are immune to XSS. You can also set the Secure cookie flag to guarantee the cookie is only sent over HTTPS. However, cookies are vulnerable to a different type of attack: cross-site request forgery (CSRF). In this case CSRF could be prevented by using some kind of synchronized token patterns. There is good implementation in AngularJS, in Security Considerations section.

An article you might want to follow.

To illustrate how it works in general:

---

Few words about JWT itself:

To make it clear there is really cool JWT Debugger from Auth0 guys. There are 2 (sometimes 3) common claims types: public, private (and reserved).

An example of JWT body (payload, can be whatever you want):

{     
  name: "Dave Doe",
  isAdmin: true,
  providerToken: '...' // should be verified then separately
}

More information about JWT structure you will find here.

这篇关于前端和后端的JWT令牌策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！