OAuth2返回JWT代替access_token

问题描述：

我目前正在使用bshaffer PHP库here构建OAuth2提供程序。OAuth2返回JWT代替access_token

我发现了IETF draft specifications，它们概述了具体调用JSON Web Tokens作为授权授权和客户端认证的实现。

然而，我感兴趣的实现是返回JWT来代替常规访问令牌，如here所示。在死链接的情况下，访问令牌响应被粘贴在下面。

{  
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJpZCI6IjYzMjIwNzg0YzUzODA3ZjVmZTc2Yjg4ZjZkNjdlMmExZTIxODlhZTEiLCJjbGllbnRfaWQiOiJUZXN0IENsaWVudCBJRCIsInVzZXJfaWQiOm51bGwsImV4cGlyZXMiOjEzODAwNDQ1NDIsInRva2VuX3R5cGUiOiJiZWFyZXIiLCJzY29wZSI6bnVsbH0.PcC4k8Q_etpU-J4yGFEuBUdeyMJhtpZFkVQ__sXpe78eSi7xTniqOOtgfWa62Y4sj5Npta8xPuDglH8Fueh_APZX4wGCiRE1P4nT4APQCOTbgcuCNXwjmP8znk9F76ID2WxThaMbmpsTTEkuyyUYQKCCdxlIcSbVvcLZUGKZ6-g", 
    "client_id":"CLIENT_ID", 
    "user_id":null, 
    "expires":1382630473, 
    "scope":null 
}

到位的正常授权补助定期生成的访问令牌的返回JWT。客户和用户凭据授权对我来说更为重要，因为我们只处理第一方API访问。

此实现看起来很理想，因为我不需要维护一个生成的令牌存储区，从而限制了所需的基础架构数量。在某些时候，如果我们向第三方开放API，我们需要一个用于各种pub/priv密钥的密钥存储区来验证每个客户端的令牌，并在某些恶意方偷走加密密钥时限制风险。

我觉得这是一个很好的依赖于非对称加密和SSL/TLS的实现。但是，我是否存在潜在的安全风险？

你的问题的真实性，你得到的标记示例不使用标准的JWT索赔。例如，它具有'client_id'而不是'sub'（这可能来自旧规格，目前的要求在这里：https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-11 ＃section-3） – stash 2014-10-30 16:43:34

谢谢！我从中得到回应的文档必须是过时的，v1.5正在生成带有“sub”，“iss”等的标记。请注意仔细检查。 – Jamie 2014-10-30 17:42:12

缺点是，如果没有令牌数据库，您无法撤消发布的JWT令牌。 – 2014-10-31 10:13:12

答

JWT上的签名只会保护内的所有内的篡改，但不能保护令牌外部的声明。因此，您的结构中的expires字段未受到保护，可能会被篡改。

为了防止篡改，您要使用exp claim。

两个有效的解决方案是：

仔细检查expires对exp

下降expires，只是使用exp

你可能更喜欢一个比其他根据您的要求。就个人而言，我会保持简单，并遵循（2）

我喜欢你关于exp的建议。问题：如果我正在实现refresh_token流，我应该在JWT中将刷新标记添加为声明还是将其添加为refresh_token JSON属性？ – 2015-02-03 21:28:34

我建议您将其添加为refresh_token JSON属性。注销时，您可以撤销access_token或refresh_token – Vikash 2015-03-04 07:26:14

OAuth2返回JWT代替access_token

相关推荐