在每个请求中包括承载令牌并保持用户登录 [英] Including bearer token in every request and keeping the user logged

查看：66
本文介绍了在每个请求中包括承载令牌并保持用户登录的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我有一个在特定服务器上运行的API，当您向登录端点发送成功请求时，它会为您提供JSONWEBTOKEN. 在第二台服务器上，我正在运行一个网站，该网站正在将请求发送到API.我想要的是保存用户登录时收到的JWT令牌，并保存它，这样用户的下一个请求也将与他们一起发送Bearer令牌，同时保持用户的登录状态.

我尝试使用

在请求中包括快速会话 

app.use(session({ secret: 'keyboard cat', cookie: { maxAge: 60000 }}))

但是我找不到如何完全使用它来完成我在文档中需要的工作.

解决方案

快速解答

我想要保存的是用户登录时收到的JWT令牌，并保存

在您的Web服务器中，创建令牌.因此，您可以存储在任何地方(db).当您需要诸如以下功能时，通常需要这样做:撤消令牌或停止某些用户的任何活动.因此，您是网络管理员，请删除此用户并标记电子邮件和/或令牌，以便当该用户执行新的http调用时，系统将显示不允许您..."

如果没有此功能，请不要将令牌存储在服务器中.只需创建它并发送给用户即可.常见的javascript框架会将令牌存储在浏览器中的某些位置(如 localstorage )，并且当需要调用API时，javascript框架只是从localstorage获取令牌.

因此，用户的下一个请求也将与他们一起发送Bearer令牌

如果您的前端有一个有效的令牌，则可以在下一个对api的请求中使用它.

同时保持用户登录状态

那是另一个世界:在安全方面强烈建议检测空闲用户并终止其会话.

无论哪种方式，无论您需要保持用户登录，我都会向您展示两种策略:

增加有效期(不推荐)

尽可能长地配置快速到期和令牌到期.

刷新

在Web服务器中创建一个类似于/refresh的端点.该端点将负责刷新您的Web Express服务器中的会话，并刷新您的令牌(如果已过期).最终，您使用javascript(当前框架)的浏览器中的网络int必须间隔一定时间到达其端点.这样，您的会话和令牌将永不过期.

这也可能有助于检测空闲用户.例如，使用javascript，您可以检测到点击或其他事件.因此，在这种情况下，请调用/refresh端点.活跃用户将拥有有效的Web Express会话和更新的令牌.闲置的用户不会触发此点击事件，因此不会调用/refresh端点.当用户欢迎时，执行一次单击，/refresh端点将被调用，并且必须返回标志，表明Web Express会话已过期且令牌也已过期.

外部化您的安全引擎

如果您有更多的网站，api，mobil app等，请阅读本节

根据当今世界一流平台的工作方式，以及如果您将拥有更多网站/apis/etc，我建议您使用oauth2.

您在api中使用/login端点的位置更近一些.您的工件将是:

  • 安全服务器/引擎(管理身份验证和授权)
  • api
  • 网络

此安全引擎必须以最简单的方式具有两个端点:

/登录

交换令牌的有效凭证

  • 网站，系统或应用程序不得在其内部实现此逻辑.必须从其Web服务器后端(快速)或使用ajax的浏览器中的javascript使用/login.
  • 生成的令牌必须发送到网络.然后网络会将其发送到api.

/validate-token:

此端点负责检查令牌是否有效，签名正确，已过期等

Apis ，必须接收令牌并检查消耗其/validate-token 端点的验证.如果是有效令牌，则api必须执行请求的操作，例如列出客户，在db上持久保存值等.如果此端点返回错误，则api将向网络通知此错误，并且网络必须向用户显示错误. /p>

如果您具有Api网关，请在其上配置此终结点，以便每次调用api时，api网关都会执行传入令牌的验证.

Oauth2需要很多其他端点

Oauth2需要许多其他端点和功能，例如:您所有应用程序的唯一表单登录，授予同意流，刷新令牌，撤消令牌，用户管理等

最后，我的建议是开发自己的安全引擎，或者如果您没有时间(总是)搜索一些oauth2服务器或oauth2提供程序并使用它！

查看以下oauth2文档或流程样本:

并检查我自己的oauth2提供程序:

I have an API running in a certain server, when you send a successful request to the login endpoint, it provides you with a JSONWEBTOKEN. On my second server, I'm running a website which is sending the requests to the API. What I want is to save the JWT token the user receives when logging in, and saving it so every next request from the user also sends the Bearer token with them, while keeping the user logged.

I have tried including express-session in the requests, using 

app.use(session({ secret: 'keyboard cat', cookie: { maxAge: 60000 }}))

But I can't find how to exactly use it to do what I need in the documentation.

解决方案

Quick Answer

What I want is to save the JWT token the user receives when logging in, and saving it

In your web server, you create the token. So you could store anywhere (db). This is commonly required when you need a functionality like : revoke tokens or stop any activity of certain user. So you web admin, delete this users and flag the email and or token, so when this user performs a new http invocation, system will show "Your are not allowed... "

If you will not have this functionality, dont't store the token in your servers. Just create it and send to the user. Common javascript frameworks, will store this token some where in the browser like localstorage and when an invocation to an api es required, javascript frameworks just get the token from localstorage.

so every next request from the user also sends the Bearer token with them

If you have a valid token in your frontend, you could use it to every next request to the api.

while keeping the user logged

That's is another world: detect idle users and expire its sessions is highly recommended in security terms.

Any way if you need keeping the user logged no matter what, I show you two strategies :

Increase expiration(not recommend)

Configure the express expiration and token expiration a long as you can.

Refresh

Create an endpoints like /refresh in your web server. This endpoints will be responsible to refresh session in your web express server and refresh your token if is already expire. Finally your web int in the browser with javascript (current frameworks) must hit to his endpoint at intervals. With this your session and token will never expire.

Also this could help to detect an idle user. For example with a javascript you could detect clicks or another events. So in this event call to the /refresh endpoint. An active user will have valid web express session and renewed tokens. An idle user won't trigger this click event, so /refresh endpoint is not invoked. When user welcome, performs a click, /refresh endpoint will be invoked and must return flags , indicating that web express session is expired and tokens are expired also.

Externalize your Security Engine

If you have more websites, apis, mobil apps, etc, read this section

Based on how nowadays world class platforms works and if you will have more websites/apis/etc I advice you to use oauth2.

You are a bit closer with /login endpoint in your api. Your artifacts will be:

  • security server/engine (manages authentication and authorization)
  • api
  • web

This security engine must have in the most easy way, two endpoints:

/login

Exchange valid credentials for a token

  • Websites, systems or apps must not implement this logic inside it. Must consume /login from its web server backend (express) or from javascript in the browser with ajax.
  • Generated token must be sent to the web. And web will send it to the apis.

/validate-token :

This endpoints is responsible to check if token is valid, correct signature, expired, etc

Apis, must receive the token and check its validation consuming /validate-token endpoint. If is a valid token, api must perform the requested operation like list customers, persist values on the db, etc. If this endpoint returns an error, api will notify to the web this error and web must show an error to the user.

If you have an Api Gateway, configure this endpoints on it, so every call to your api, the api gateway will perform the validation of incoming token.

Oauth2 need a lot of others endpoints

Oauth2 need a lot of others endpoints and functionalities like: unique form login for all your apps, grant consent flow, refresh token, revoke tokens, user managements, etc

Finally my advice is to develop your own security engine or if you have no time (always) search some oauth2 server or oauth2 provider and use it!

Check these oauth2 documentations or flow samples:

And check my own oauth2 provider:

这篇关于在每个请求中包括承载令牌并保持用户登录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！

查看全文
相关文章
其他开发最新文章
热门教程
热门工具
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆