identity4 系列————开篇概念

前言

identity4 其实是openid connection， 那么我们还听说过openid 还有 oauth 2.0

那么下面就介绍一下Oath 2.0和openid 还有 openid connection

正文

网上说openid 是身份认证， 然后oauth2.0 是授权。

真的是这样吗？

直接看官网。

https://openid.net/what-is-openid/

OpenID allows you to use an existing account to sign in to multiple websites, without needing to create new passwords.

You may choose to associate information with your OpenID that can be shared with the websites you visit, such as a name or email address. With OpenID, you control how much of that information is shared with the websites you visit.

With OpenID, your password is only given to your identity provider, and that provider then confirms your identity to the websites you visit.  Other than your provider, no website ever sees your password, so you don’t need to worry about an unscrupulous or insecure website compromising your identity.

OpenID is rapidly gaining adoption on the web, with over one billion OpenID enabled user accounts and over 50,000 websites accepting OpenID for logins.  Several large organizations either issue or accept OpenIDs, including Google, Facebook, Yahoo!, Microsoft, AOL, MySpace, Sears, Universal Music Group, France Telecom, Novell, Sun, Telecom Italia, and many more.

这上面介绍了，openid 作用是做到去中心化登录，实现信息共享。

You may choose to associate information with your OpenID that can be shared with the websites you visit, such as a name or email address. With OpenID, you control how much of that information is shared with the websites you visit.

上面提及到了，你能选择自己的哪些信息被共享给你要登录的网站, 也就是授权给网站可以去idp（identity provider）获取哪些信息。

openid 要做的是实现去中心化登陆，实现信息共享，信息共享才是最终目的。

那么有 openid 感觉已经可以搞定了，已经实现我们的信息共享的目的了，要啥oauth（open oauthorization）。

openid 的确目的是为了去中心化登录，让用户选择自己的信息进行授权给对应的网站，但是关键是如何授权呢？ openid 可没有指定什么授权。

来看下oauth 提供的方案,不仅提供了网站还提供给了桌面等授权:

看：https://oauth.net/2/

OAuth 2.0 is the industry-standard protocol for authorization. 

OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. 

This specification and its extensions are being developed within the IETF OAuth Working Group.

这里说明了oauth2.0 专注于，对网站、桌面端提供授权。

很多人这里就开始联想了，认为oauth 2.0 是对openid的补充。

其实oauth 2.0 跟 openid 没有任何关系。 openid 是实现去中心化登录实现信息共享， oauth 2.0 是为了实现对第三方应用授权。

oauth 2.0 中就没提到登录这回事， 比如访问我的某个url，我就会给你一个access_token,你通过我的这个access_token 就可以访问我的计算功能的api，我就不需要你登录。

同样openid，也不一定要使用你oauth 2.0去授权， 未来还会出现其他方案的嘛。

所以也不要说什么openid 管什么认证，oauth 2.0 管什么授权，搞得他们好像有啥关系一样。openid 是一套去中心化身份认证，为了实现信息共享。

有些人提及左边是openid 认证，右边是oauth 授权，我个人认为这是不正确的。这个就是实现openid，授权用的是oauth 2.0 方案。

那么openid connection 是什么呢?

https://openid.net/connect/

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server,

 as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.

这里可以看到openid connection 结合了openid这种去中心化身份验证的场景加上了oauth 2.0的授权方式，是他们的结合体。

里面也说了openid2.0 和 openidconnection的区别：

OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.

好了，现在知道他们的区别了，关于auth2.0 还是有必要看一下的，比较要学的是identity4，然后identity4基于openid connection，openid connection 授权又是在oauth 2.0 的基础上。

看阮一峰的网址吧，太清晰了，没有从新整理的必要性：http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

这里新手值得注意这里的授权和我们的获取token 访问api授权不一样。

怎么不一样呢？ 这里解释一下。

比如我们以前的是去获取到了token，然后呢，通过角色或者什么策略去访问这个api，判断是否是这个角色可以访问。

这种授权可以理解为内部授权。

OAuth协议一般用于用户决定是否把自己在某个服务商上面的资源（比如：用户基本资料、照片、视频等）授权给第三方应用访问。

可以看到这里oauth 协议呢，指的是第三方授权，这个很重要，而不是说在你们内部获取一个token，然后这个token 验证用户是否可以访问这个接口。

举个例子，简书通过qq登录可以获取到qq的头像，名字等。如果你授权后， 简书就可以拿到你qq的头像和名字，否则就拿不到。

我们内部的授权是针对的是内部的资源（api等），第三方授权针对的是开放的资源，比如说在服务器的名字头像等。

还是以简书这个例子来说。

比如简书上跳转到qq，然后可以勾选哪些信息授权给简书（有些是不能选的，因为简书要求一定要获取，不获取就不给你登录），用户输入账户密码后，就跳转到了简书。

想下面这种灰色的就是不能去掉的。

当我们登录完后跳转到简书后，发现简书有了我的qq头像了。

我们来抓包看下:

当qq 登录完成之后:

这里302跳转会简书。

请求了简书的这个callback。

拿到这个code 后，获取access_token,然后access_token 可以获取到用户的openid，通过openid 和 access_token获取到用户的头像和名字。

这样看可能还是会迷糊。

直接现场演示如何接入qq。

qq 第三方登陆提供了两种模式：

一种是service-side 模式， 这种对应的是authorization code 模式。

另外一种是client-side 模式，implisit grant type 模式。

别人已经写了，所以这里就不写了。

https://www.php.cn/js/js-Server-side.html

implicit grant type 模式可能别人有误解哈，有些人直接翻译过来是简易模式， 认为这种方式不安全，感觉没人会使用。

其实不是的，这种模式用的还挺多的。

下面是不同场景。

举个例子，比如隔壁前端部门要做个工具，他们纯粹调用你们部门的api，那么直接implicit grant type 模式就好了。

他们不需要服务器保存什么数据，只需要授权api 访问就好了。这样安全达到了，且又让项目复杂度变得更加简单。

之所以有几种模式，是因为场景不同， 需要的安全程度不一样。

结

identity 章节开始了，上面只是个人整理，主要是介绍了一下概念，主要介绍openid是中心化登录的一套信息共享方案， 同样oauth 2.0 跟openid 没有任何关系，准备来说oauth 2.0 是一个对第三方授权的方案，所以整理一下概念，如有错误望请指出。