OAuth2.0

OAthu2.0参考链接1

OIDC（OpenId Connect）身份认证参考链接

一、定义

        OAuth2.0是OAuth协议的延续版本，但不向前兼容OAuth 1.0(即完全废止了OAuth1.0)。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749。Oauth2定义了一组想当复杂的规范。涉及到：Roles角色、Client Types客户端类型、Client Profile客户端描述、Authorization Grants认证授权、Endpoints终端等。

        OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

二、 OpenID Connect（OIDC）

        OIDC是一个OAuth2上层的简单身份层协议。它允许客户端验证用户的身份并获取基本的用户配置信息。OIDC使用JSON Web Token（JWT）作为信息返回，通过符合OAuth2的流程来获取。

        OAuth2与资源访问和共享有关，而OIDC与用户身份验证有关。

        OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散性。OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。

        对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。

参考资料1

三、相关区别

        OAuth是OpenID的一个补充，但是完全不同的服务。

        OAuth 2.0是OAuth协议的下一版本，但不向后兼容OAuth 1.0。

     

        JWT提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。JWT是一种安全标准。基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证成功，会产生并返回一个Token（令牌），用户可以使用这个token访问服务器上受保护的资源。

        Oauth2和jwt是完全不同的两种东西，一个是授权认证的框架，另一种则是认证验证的方式方法（轻量级概念）。OAuth2不像JWT一样是一个严格的标准协议，因此在实施过程中更容易出错。尽管有很多现有的库，但是每个库的成熟度也不尽相同，同样很容易引入各种错误。在常用的库中也很容易发现一些安全漏洞。

        OAuth2.0和JWT区别参考链接

三、认证过程

四、四种认证模式

1.隐式授权模式（Implicit Grant）

•  第一步：用户访问页面时，重定向到认证服务器。
•  第二步：认证服务器给用户一个认证页面，等待用户授权。
•  第三步：用户授权，认证服务器想应用页面返回Token
•  第四步：验证Token，访问真正的资源页面

2. 授权码授权模式（Authorization code Grant）

• 第一步：用户访问页面
•  第二步：访问的页面将请求重定向到认证服务器
•  第三步：认证服务器向用户展示授权页面，等待用户授权
•  第四步：用户授权，认证服务器生成一个code和带上client_id发送给应用服务器
•          然后，应用服务器拿到code，并用client_id去后台查询对应的client_secret
•  第五步：将code、client_id、client_secret传给认证服务器换取access_token和  
•          refresh_token
•  第六步：将access_token和refresh_token传给应用服务器
•  第七步：验证token，访问真正的资源页面

 案例Github自取:https://github.com/PinkPig-cq/springSecurityoAuth

 3密码模式（Resource Owner Password Credentials Grant）

•  第一步：用户访问用页面时，输入第三方认证所需要的信息(QQ/微信账号密码)
•  第二步：应用页面那种这个信息去认证服务器授权
•  第三步：认证服务器授权通过，拿到token，访问真正的资源页面

优点：不需要多次请求转发，额外开销，同时可以获取更多的用户信息。(都拿到账号密码了)

缺点：局限性，认证服务器和应用方必须有超高的信赖。(比如亲兄弟？)

应用场景：自家公司搭建的认证服务器

 4.客户端凭证模式（Client Credentials Grant）

•  第一步：用户访问应用客户端
•  第二步：通过客户端定义的验证方法，拿到token，无需授权
•  第三步：访问资源服务器A
•  第四步：拿到一次token就可以畅通无阻的访问其他的资源页面。

这是一种最简单的模式，只要client请求，我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。

因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。