使用JWT进行App身份验证和授权

Asm*_*kim 5 security oauth-2.0 jwt asp.net-web-api

我正在浏览Oauth2文档,并认为这是一种宽容的安全性,因此我尝试使用特殊方案实现JWT令牌,如图片中的移动应用程序与Web API进行通信.

注意:我不喜欢Oauth2刷新令牌的想法,因为它们可能会被盗并允许并行使用(由合法和恶意用户),除非您通过旋转它们来实施盗窃检测(在每次请求时刷新刷新令牌),在这种情况下为什么要使用它们?

身份验证流程如何工作:

  1. 用户使用凭据登录获得的生命周期为20分钟.
  2. 到期后,通过点击数据库检查它是否被列入黑名单(重新登录)并且如果没有检查是否用于生成新令牌,则刷新jwt.
  3. 如果它从未用于刷新,则接受并用于发出低级访问令牌.
  4. 如果之前使用过令牌,或者客户端+设备+用户与其父级用户不同,则会进行凭据检查(密码或锁屏代码)
  5. 如果通过,此检查会发出一个新的一年级令牌,该令牌将所有父级和子级列入数据库,这就像新的第一个用户登录一样.
  6. 如果锁屏失败,则会向用户显示登录屏幕.

问题是:

  1. 什么是可能的安全漏洞?(我发现了两个使用案例:被盗的有效访问令牌与Oauth令牌持续20分钟相同的问题.此处没有任何损失.窃取睡眠令牌:用户未登录7天,令牌被盗并被使用,直到用户再次登录或者令牌链在3个月的持续时间后重新发布 - 我们的政策 - 这种盗窃的机会很小,因为令牌必须在用户对应用程序的最后请求中截获,比窃取Oauth2刷新令牌更轻薄)
  2. 在此计划中,玩家可能会对应用程序造成什么样的用户体验问题?

jwt auth flow

Mvd*_*vdD 0

OAuth2 refresh tokens are not meant to be used by mobile clients. Using refresh tokens requires client credentials, which cannot be stored securely in a mobile application.

Refresh tokens are used from confidentials clients (server side web applications for example). They are often renewed when used (server sends back new access and new refresh token). In contrast to access tokens, the refresh token is only sent to the authorization server, not the resource (API) server.

Regarding your auth flow. Step 2 is the weak link IMO. You allow the client to use an expired token to generate a new access token. So if I find your phone and access the device, it will allow me to get a fresh access token and impersonate you.

You could force the client to refresh the token every say 15 min., but then you have to define what happens if the app gets closed or the device is turned off? Is it okay to re-authenticate the user again?