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

问题描述

我正在编写一个应用程序，前端在 emberjs 中，后端/服务器端在 nodejs 服务器中.我配置了 emberjs，以便用户可以使用 3rd 方 Oauth(谷歌、推特、Facebook)登录/注册.我有一个用 express nodejs 服务器编写的后端，用于托管 RESTful API.

我没有连接到 emberjs 的数据库，我认为无论如何我都不应该，因为它是严格的客户端代码.我计划使用 JWT 在客户端和服务器端之间进行通信.当用户使用他们的 oauth 凭证登录时，我从提供者那里得到一个 JSON 对象，其中包含 uid、名称、登录名、access_token 和其他详细信息.

我正在努力选择如何处理用户注册的策略.没有注册过程，因为它是 OAuth.所以流程是如果用户不在我的数据库中，则创建它.我不支持电子邮件/密码身份验证.用户第一次使用 OAuth 提供商登录时的流程是什么?emberjs 是否应该在每次登录时将所有详细信息发送到后端，以便后端可以向数据库添加新用户?

我的 JWT 主体应该是什么?我在想 uid 和提供者提供的访问令牌.我在这里可以想到的一个问题是提供者特定的访问令牌可以更改.用户可以从提供商的站点撤销令牌并使用 emberjs 再次注册.

我愿意在任何其他 javascript 客户端框架中编写前端，如果它更容易的话.

解决方案

如果我们不仅要讨论工作，还要讨论安全的无状态身份验证，您将需要考虑使用 access 和 <代码>刷新令牌.

1. 访问令牌是提供对受保护资源的访问的令牌.Expiration 此处可能会在大约 1 小时内安装(取决于您的考虑).

2. Refresh token 是一种特殊的令牌，用于生成额外的访问令牌，以防它过期或用户会话已更新.显然，您需要使其寿命更长(与 access token 相比)并尽可能安全.Expiration 此处可能会在大约 10 天或更长时间后安装(也取决于您的考虑).

仅供参考:由于 refresh tokens 是长期存在的，为了使它们真正安全，您可能希望将它们存储在您的数据库中(很少执行刷新令牌请求).这样，假设您的刷新令牌以某种方式被黑客入侵并且有人重新生成了 access/refresh 令牌，当然您会失去权限，但是您仍然可以登录系统，因为您知道登录/通过(以防您以后使用它们)或仅通过任何社交网络登录.

---

在哪里存储这些令牌?

基本上有2个常见的地方:

1. HTML5 网络存储(localStorage/sessionStorage)

很高兴去，但同时也有足够的风险.可以通过同一域上的 javascript 代码访问存储.这意味着，如果您遇到

---

关于 JWT 本身的几句话:

为了说明这一点，Auth0 人员提供了非常酷的 JWT 调试器.有 2 种(有时是 3 种)常见的声明类型:public、private(和 保留).

JWT 主体示例(有效负载，可以是任何你想要的):

<代码>{名称:Dave Doe"，isAdmin: 真,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 Token 策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！