OAuth 2.0 和 OpenID Connect 的基本原理和区别（干货）

基本原理

首先要明确OAuth OpenID Connect学习起来比较难，对谁都会比较难，所以心态要放好，因为有很多专业属于、缩写等等，你要是之前不知道，就基本上很难看懂。而且OAuth和OpenID Connect不像HTTP这样的协议，有固定的格式，OAuth和OpenID Connect其实没有很固定的格式，没有人告诉你，一定要怎么做。
所以本文都是大白话，让大家更容易看懂。

为什么要用OAuth 和 OIDC来做授权和身份验证？

原来，是怎么进行身份验证的？
简单的表格登录验证模式，密码哈希存在数据库里面，用户输入用户名密码，找后台数据库进行比对，从而进行身份验证。

但是这种模式非常不好，不好的原因有两个：

1. 不安全：需要自己去考量安全技术、更上最新的安全算法
2. 成本高：需要自己维护验证的流程

所以OAuth和OpenID Connect，就是来取代这种传统简单的验证方式，成为行业身份验证的最佳实践。

历史

2006/2007 没有智能手机，当时的Web App也会面临很多的登录问题，十年前用的是简单登录（表格和cookie的模式），采用SAML进行跨站点SSO（SAML其实比OAuth还难懂，更晦涩）
所以，对于手机端的应用程序，你可以登录进行进行使用，但是如果你关掉应用程序，如何保持用户的登录状态，cookie又不能支持手机应用，所以如何来解决这个问题呢？
其次，另外一个问题是如何进行委派授权呢？为什么要进行委派授权，因为由于app越来越多，有些app开发不一定很好，如果你在上门注册你的用户名和密码在他们的数据库里面，这样会造成安全风险，因为你把密码给了一个不守信的应用。
所以，总得来说OAuth和OpenID Connect就是想实现，不给这些三流应用程序密码，而是让三流应用程序去找大厂的应用程序进行身份验证，这样密码只给大厂应用，比如微信微博，然后微信微博就充当一个身份标识提供方
所以，委派授权让应用可以获得你所允许的用户资料内容，比如你允许一个三方应用程序访问你的微信头像、昵称，而你的生日、年龄则不被获得。

举个反面例子：

yelp.com Web应用如上图。
这里我们输入了Gmail的用户名和密码，注意这里的密码不是yelp.com的密码，而是你自己邮箱的密码，yelp.com获得了你Gmail的用户名密码，这样的话，yelp就可以直接登录你的私人邮箱，这样是非常不安全的。所以这是一个非常糟糕的身份验证方式。

所以，怎么来解决这样的问题呢？我们也不可能每个应用都用不同的用户名和密码。
但是，就像之前所说，虽然我们不信任yelp，但是我们信任Gmail，如果验证发生在Gmail那边，而是yelp，Gmail只需要告诉yelp，我是我，我能够进行访问，这样就完美了。
所以，就形成了OAuth 2.0。

如上图，是经典的OAuth flow，yelp提示可以通过google来进行登录，然后页面就会跳转道google.com，然后我在google.com的页面上进行用户名和密码登录，这样身份验证的密码其实是输在了google这端，而不是yelp这个我们不认识的应用程序，这样显然就安全多了。登录了谷歌之后，google就会问用户，“你允许yelp去访问你的公开资料和联系人吗？”，如果你点yes，那么google来进行身份验证的流程就走完了，然后就又跳转到yelp.com/callback。然后，yelp就可以去找google.com的资源API请求所需的资源（公开资料和联系人）。
所以，验证是由google来完成的，此外google还给了yelp一些用户信息。这是由O