OAuth2.0协议(四)、基于OAuth2.0的OIDC认证协议

    OIDC（OpenID Connect）协议建立在OAuth2.0协议的基础上，这里需要分清OAuth2.0是一个授权协议，而OIDC是一个认证协议，特别容易搞混。只是OAuth授权框架中包含了部分需要调用认证的信息，而IODC协议利用了OAuth2.0的认证流程（或者利用了去管道、通道）并增加了输出了id_token和OpenId（认证结果和标识）。可以理解：

IODC【OpenID Connect】 = OAuth2.0【授权协议】 + 身份认证； 

IODC定义了三个角色：

• EU（End User）：最终用户；
• RP（Relying Party）：认证服务的依赖方，即三方服务；
• OP（OpenID Provider）：提供身份认证服务方；

IODC的三个角色与OAuth2.0的四个角色的映射关系为：

 IODC对OAuth2.0最主要的扩展就是在获取access_token的时候，增加返回了id_token,而id_token是一个安全令牌，是一个授权服务器提供的包含用户信息（由一组Cliams构成以及其他辅助的Cliams）的jwt格式的数据结构。由于是jwt格式的令牌，所以也可以设置以下属性值，可以与jwt中的payload属性对应，如下：

• iss: 令牌的颁发者，其值就是身份认证服务（OP）的 URL；
• sub: 令牌的主题，其值是一个能够代表最终用户（EU）的全局唯一标识符；
• aud: 令牌的目标受众，其值是三方软件（RP）的 app_id；
• exp: 令牌的到期时间戳，所有的 ID 令牌都会有一个过期时间；
• iat: 颁发令牌的时间戳；

{
    "iss": "https://server.example.com",
    "sub": "24400320",
    "aud": "s6BhdRkqt3",
    "nonce": "n-0S6_WzA2Mj",
    "exp": 1311281970,
    "iat": 1311280970,
    "auth_time": 1311280969,
    "acr": "urn:mace:incommon:iap:silver"
}

    虽然IODC是基于OAuth2.0协议，并且角色信息也可以进行映射，但是需要注意：OAuth2.0规范中定义了四种授权类型（授权流程）来应对不同的环境，并且后续还增加了PKCE协议来应对单页（SPA）或者没有服务端的APP， 而OIDC认证流程只有三种，分别是：

• Authorization Code Flow：使用OAuth2.0的授权码来换取access_token和id_token，即本身会走OAuth2.0的授权码认证流程；
• Implicit Flow：使用OAuth2.0的Implicit流程获取 access_token和id_token，对应OAuth2.0的隐式许可流程，但是这种认证存在安全隐患一般不建议使用（之前说过使用PKCE代替）；
• Hybrid Flow：混合Authorization Code Flow + Implicit Flow；

    OAuth2.0中还有资源拥有者凭据许可类型（Resource Owner Password Credentials Grant）、客户端类型（Client Credentials Grant）的授权流程，为什么OIDC没有对应的认证流程呢？ 

    资源拥有者凭据许可类型的使用场景是三方服务本身是被平台（授权服务、受保护资源服务）信任的，或者本来就是一个公司或者团队开发的，该流程直接使用 用户名和密码换取access_token，既然用户名称密码都给到RP（Reply Provider）了，就不需要id_token了；而客户端授权类型是三方服务端直接调用受保护资源服务，其中根本就没有EU（End User）的参与，没有用户更谈不上用户的身份认证了。这也能反映出授权和认证的差异，并且只使用OAuth2.0来做身份认证是远远不够的，也是不合适的。

    

IODC基于OAuth2.0授权码认证流程（最完整流程）的单点登录流程如下：

OIDC VS OAuth2.0的理解：

OAuth2.0是一个授权协议或者思想，只是认证的前提是需要登录，即利用了认证；OIDC建立在OAuth2.0的基础上，并且只是在授权码许可流程的第二阶段增加返回了OpenId（表示用户认证的唯一结果）、id_token（jwt类型）。

access_token VS id_token的理解：

    access_token是 是否允许代表（access），而id_token是用户态的标识。授权过程利用了登录，而认证利用了授权的通道，增加了id_token的返回【既然OAuth2.0已经有了通道流程，就没有必要自己再造轮子了】。

    一般情况下，id_token的过期时间比access_token的短，access_token还可以使用refresh_token刷新access_token，即用户登录授权完成后不久，用户登录态就失效了，但是三方服务还可以定时刷新access_token，在后端帮处理用户授权的数据（即调用受保护资源服务）。

OIDC的特性和好处：

1. OIDC使得身份认证可以作为一个服务存在；
2. OIDC可以很方便的实现SSO（跨顶级域）；
3. OIDC兼容OAuth2，可以使用Access Token控制受保护的API资源；
4. OIDC可以兼容众多的IDP作为OIDC的OP来使用；
5. OIDC的一些敏感接口均强制要求TLS，除此之外，得益于JWT,JWS,JWE家族的安全机制，使得一些敏感信息可以进行数字签名、加密和验证，进一步确保整个认证过程中的安全保障；