oauth2.0 关于RESTful API授权的最佳实践和一些疑问

lf5gs5x2  于 5个月前  发布在  其他
关注(0)|答案(1)|浏览(107)

我目前正在开发一个后端服务器在js.js,用户可以登录或注册在客户端使用一个基本的电子邮件和密码的方法或社会登录方法(例如,谷歌,Facebook)。在我的研究,我遇到了两个潜在的方法:JWT(JSON Web令牌)和OAuth 2.0。我有几个问题,关于这一点:
1.我应该使用JWT进行授权,OAuth 2.0,还是两者的组合?
1.如果我选择JWT,在服务器端验证它们的最佳实践是什么?使用密钥验证它们是否足够,或者是否有其他推荐的实践?
1.如果我选择OAuth 2.0,我是否需要创建自己的代理授权服务器来管理使用电子邮件和密码而不是第三方社交帐户注册的用户?
1.在生产级别是否有其他常用的授权技术来确保可靠的安全性?
此外,推荐任何有助于理解这些概念的学习资源或材料?

gupuwyp2

gupuwyp21#

是的,通常将JWT(JSON Web令牌)与OAuth 2.0结合使用,用于身份验证和授权的不同方面。下面是一个常见的场景:
OAuth 2.0认证:使用OAuth 2.0处理初始身份验证流程,特别是对于社交登录等场景(例如Google、Facebook)。当用户使用第三方身份提供商登录时,(OAuth 2.0认证服务器),您的服务器会收到一个授权码。用这个授权码交换一个访问令牌,也可能是一个刷新令牌。然后,访问令牌可以用于访问用户在第三方服务上的资源。用于授权的JWT:一旦您的服务器验证了用户(通过OAuth 2.0或其他方法,如电子邮件/密码),您可以生成一个JWT来表示用户的身份和相关声明。JWT可以包括用户角色,权限和其他相关细节等信息。此JWT可以发送到客户端,客户端可以将其包含在对您的API的后续请求的标头中。然后,您的服务器可以验证JWT,以确保请求是基于所包含的声明进行授权的。通过组合OAuth 2.0和JWT,您可以利用OAuth 2.0进行初始身份验证流,并利用JWT管理应用程序中的授权和访问控制。
下面是一个简化的流程:
用户通过OAuth 2.0登录(例如,Google,Facebook)。您的服务器从OAuth 2.0提供商获得访问令牌。您的服务器生成包含用户声明的JWT(角色,权限)。此JWT发送到客户端。客户端将JWT包含在API请求的标头中。您的服务器验证JWT以授权请求。这种方法提供了行业-标准身份验证(OAuth 2.0)和灵活的无状态授权机制(JWT)。值得注意的是,具体细节可能会因您的应用程序要求和集成的身份提供程序而异。

相关问题