移动认证方法、JWTs和刷新令牌
REST Api目前通过返回JWTS形式的访问和刷新令牌来对用户进行身份验证。本地（用户名/密码）和oauth2.0（目前只有Google）流都可用，因为我为用户提供了这两个不同的身份验证选项。
所有著名的应用程序都没有提示用户进行身份验证，比如说每周或者最糟糕的是每天，但我仍然相信他们的身份验证实践（几乎）是完美无瑕的。
>
是否应该创建一个特定的endpoint（或多个endpoint），以便仅在user-agent标头告诉移动设备正在调用API时才提供不过期令牌？
-
null
共有1个答案
我不认为这个需求形成得很好，感觉它是基于产品所有者的笼统声明，没有考虑成本和收益：
- Gmail让我永远登录，我希望我的应用程序像那样工作
大型供应商
-
null
对于大多数公司，我会推荐这种类型的选项，这样可用性就很好：
- 从用户友好的选项开始，例如30天刷新令牌
- 如果使用密码登录，请确保密码自动填充有效-AppAuth将启用此功能
代币
-
我正在努力围绕JWT身份验证进行思考。我读了很多文章和SO问题，但是其中一些已经过时了，我仍然没有得到满意的答案。 我读过这个SO问题，从JoséF.Romaniello的回答中我明白： 使用刷新令牌，客户端在旧的访问令牌过期之前请求新的访问令牌（这是正常的，预期行为） 在移动应用上，代币永不过期 同样在 auth0 上它说： 您可以请求新的访问令牌，直到刷新令牌在DenyList上。应用程序必须
-
我通过以下方式进行身份验证 首先，我通过以下方式对AWS进行身份验证 我刚刚发现我可以用下面的命令重新配置，但我很好奇这是否是处理它的正确方法，以及是否有任何其他AWS方法提供。
-
现在我想知道如何集成刷新令牌。如何确保用户只能使用已颁发给该设备的有效刷新令牌获得新的访问令牌？或者，我是否使事情过于复杂，并分配一个刷新令牌，可以在alle设备上使用，这将是一个诀窍？ 更新：我已经研究了doorkeeper gem，它支持密码授予流。但是doorkeeper处理令牌的方式是，它将每个生成的访问令牌与相应的刷新令牌存储在数据库中。当令牌被撤消或刷新时，旧的访问令牌将失效--随着时
-
我在刷新访问令牌时得到这个错误：访问令牌无法刷新。请重新验证 这一错误此前曾在2017年4月报告过。OneLogin文档声明刷新令牌可以使用45天左右。我的刷新令牌已经有20个小时了。是文档正确还是刷新令牌的寿命更短？我可以做获取访问令牌和撤销令牌罚款。 public RootObject RefreshToken（HttpRequesterDM rDM）{restsharp.deserializ
-
问题内容： 我已经阅读了有关oAuth，AmazonRESTAPI，HTTPBasic/Digest等的信息，但无法将其全部整合为“单个”。这可能是最接近的情况- 为移动应用程序创建API- 身份验证和授权 我想建立以API为中心的网站-服务。因此（一开始）我将在中心拥有一个API，而 网站 （PHP + MySQL）将通过 cURL ， Android 和 iPhone 通过它们的网络接口进行连
-
我正在尝试使用 NodeJS 构建 RESTful API，但在 api 调用期间无法理解使用令牌对用户进行身份验证的正确方法。在阅读了一些博客和文章后，我想出了这些方法： Access Token（AT）是包含唯一userId作为JWT有效负载的JWT令牌。1天后到期。 刷新令牌（RT）是使用uuid npm包的随机uuid。与用户文档一起存储在数据库中。 过程： 当用户登录/注册服务器发布新A