2015-06-17 29 views
0

我想知道是否真的需要OpenID Connect以在OAuth2之上提供身份验证。在我看来,如果我生成JWT(JWE)作为访问令牌,并且在访问令牌中存储用户声明,角色/权限等,则不需要OpenID Connect的ID令牌。资源服务器可以验证每个请求上的访问令牌。另外,我可以保持访问令牌很小,只需要存储一个会话ID并使用声明/角色/权限填充该会话。此外,我可以在会话中设置到期值,并支持滑动到期等,甚至不处理刷新令牌。我是否缺少OpenID Connect的真正内容?使用OAuth和JWT进行身份验证但不使用OpenID Connect

我才意识到更新我要澄清我的问题有点。如果我建立了一个允许用户通过Google登录的网站,我可以看到OpenID Connect的必要性。我允许某人根据某些OAuth授权流程访问我的网站,该授权流程未证明身份验证发生。但是,如果我构建了一堆服务,并且只想发布令牌来访问这些服务资源,那么是不是足够了?如果我想让这些标记包含角色/声明,以便我可以在我的服务中进行授权决策,是不是JWT包含足够的角色/声明?如果觉得在这种情况下OpenID Connect不是必需的。

回答

0

通过要求访问令牌是JWT,同意接受JWT的用户声明,将过期/签发时间戳放入此处,并确保您以加密方式验证您实际正在执行的令牌的颁发者与OpenID Connect一样:“分析”OAuth 2.0的方式可以提供用户身份验证/身份信息。

更新:

但是,如果你并不需要用户认证的语义,你可以使用OAuth 2.0坚持。您可以使用JWT作为访问令牌,以便资源服务器(API)可以验证和检查访问令牌,并找出客户端代表谁的行为。但是请注意,该标记的拥有并不意味着用户当时在场(并经过身份验证)。

+0

感谢您的回答!我只是意识到我需要澄清我的问题。如果我建立了一个允许用户通过Google登录的网站,我可以看到OpenID Connect的必要性。我允许某人根据某些OAuth授权流程访问我的网站,该授权流程未证明身份验证发生。但是,如果我构建了一堆服务,并且只想发布令牌来访问这些服务资源,那么是不是足够了?如果我想让这些标记包含角色/声明,以便我可以在我的服务中做出授权决定,那么JWT是不是足够了? – enamrik

+0

这确实听起来像标准OAuth 2.0,客户端向资源服务器(API)呈现结构化的JWT,API知道如何验证令牌并在其中使用声明。它不提供身份验证,但允许委派访问客户端。 –

+0

谢谢,那是我等待的确认。我的同事想要引入OpenID Connect并让这些API使用id_token。我认为这是因为他们认为声明属于id_token(由规范支持),而不属于访问令牌(未由OAuth定义)。但是,由于OpenID Connect,依赖方(OAuth Client)是唯一使用id_token的应用程序,我们必须考虑我们的API RP?!这似乎是对OpenID Connect解决问题的误解。 – enamrik

相关问题