怎样浅谈Spring Security中的OAuth2
怎样浅谈Spring Security中的OAuth2，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。
首先我们来讲述大概介绍一下OAuth3。
oAuth3是一种授权协议。它主要是为了简化客户端开发人员的工作，同时为需要授权的服务提供授权流程，主要包括网站、桌面、app、小程序等。 我从官网把它几种授权模式搬过来了：
授权码（Authorization Code）
机密和公共客户端使用授权码授予类型来交换访问令牌的授权码。 用户通过重定向URL返回到客户端后，应用程序将从URL获得授权代码，并使用它来请求访问令牌。
客户凭证（Client Credentials）
客户端使用"客户端证书"授予类型来获取用户上下文之外的访问令牌。客户端通常使用它来访问有关其自身的资源，而不是访问用户的资源。
设备代码（Device Code）
设备流中的无浏览器或受输入限制的设备使用设备代码授权类型，以将先前获得的设备代码交换为访问令牌。设备代码授权类型值为urn:ietf:params:oauth:grant-type:device_code。
刷新令牌（Refresh Token）
当访问令牌过期时，客户端使用"刷新令牌"授予类型来将刷新令牌交换为访问令牌。这允许客户端继续具有有效的访问令牌，而无需与用户进行进一步的交互。
密码授权（Implicit Flow）
密码授予类型是一种将用户凭据交换为访问令牌的方式。因为客户端应用程序必须收集用户的密码并将其发送到授权服务器，所以不建议再使用此授权。该流程没有为多因素身份验证或委托帐户之类的机制提供任何机制，因此在实践中是相当有限的。
最新的OAuth 2.0安全性最佳最新实践完全禁止密码授予。
隐式流（Password Grant）
Implicit流是先前为本机应用程序和JavaScript应用程序推荐的简化的OAuth流，其中本机访问令牌无需额外的授权代码交换步骤即可立即返回访问令牌。不建议使用隐式流（有些服务器完全禁止该流），因为在HTTP重定向中返回访问令牌而未确认客户端已收到访问令牌的固有风险。公共客户端（例如本机应用程序和JavaScript应用程序）现在应该使用带有PKCE扩展名的授权代码流。
其中密码授权及隐式流两种模式在OAuth官网中是已经属于遗留模式，不在推荐了。但是我的Spring Security OAuth3系列文章主要讲述的将是密码模式，不要问我为啥？因为我是需要去解决我们现有框架中的登陆问题。所以我会着重密码模式！
个人理解的OAuth3
直到我写到这里，可能我才对OAuth3有了更新的一个认识！根据官方介绍OAuth3应该是一个第三方授权机制，即有点类似于是一个能提供公共授权机制的模块。因此在现实中这个授权模块应该具有相对的权威性，又或者说在一个范围内的应用程序，可以去请求同一个授权模块进行使用。
那这个授权模块是不是也应该是一个至少拥有用户管理功能的信息系统，能够进行身份授权，授权后授权模块允许这个账号可以使用某些功能。
但是问题来了，我在文章开头写了我们主要是搭建我们系统的登陆模块，暂时未用到对第三方应用授权。我们在这个系统中是否有必要引入OAuth3的授权机制？
说实话写到上一行，我停下来想了十分钟。我在本文中提到的系统属于我们的核心系统，包括整个公司的核心业务功能都在上面。如果以后我们在扩展其他应用时，是需要用到第三方授权的，不然就需要在每个应用中都去维护一套系统用户了。而且我们通过OAuth3也可以登陆本系统的，所以使用OAuth3.0是完全没有问题的。
看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。
