简单理解OAuth 2.0 ：
以“用户用微信登录掘金”的场景为例，这中间涉及到两个应用，但只需要登录一次微信，用户将在微信的信息，这个过程就是授权，但是用户需要登录一次微信并同意授权给掘金即可，这中间的交互过程和安全问题就是OAuth 2.0所定义的授权标准
。
对于开发者而言，如果你是微信应用的开发者，那么涉及到OAuth 2.0的部分就是提供授权服务。授权服务要做的几个事情：
1.管理第三方应用（掘金），因为不可能把用户的信息授权给任意一个应用。
2.管理访问令牌，用户同意授权且验证第三方应用后，会发放访问令牌。这里要管理令牌的生成、续期、失效、验证等。
3.管理用户数据，要保障用户数据的安全。
如果你是掘金应用的开发者，那么涉及到OAuth 2.0的部分就是提供代理服务。代理服务要做的几个事情：
1.获取授权许可，去微信授权服务注册你的信息，拿到授权许可（appid、appsecret等）。
2.获取访问令牌，引导用户去授权服务获取访问令牌。
3.获取用户数据，带着访问令牌访问授权服务获取用户数据。
可以看到访问令牌其实是OAuth 2.0中的关键，拿到访问令牌也意味着整个授权过程完成。在OAuth 2.0标准中，又因为不同的授权场景存在不同授权类型或者是获取访问令牌的方式，这也是和OAuth 1.0的不同之处。四种授权类型：
1.授权码许可，授权的过程中涉及到第三方应用的前端页面和授权服务的交互，授权码起到重定向和安全的作用。授权服务验证用户密码后先返回授权码，最终通过授权码获取到访问令牌，也是安全性最高的一个。
2.资源拥有者凭据许可，名字有点长，简单理解就是第三方应用和授权服务属于一个主体，授权服务验证用户密码后直接给访问令牌，有点单点登录的意思。
3.客户端凭据许可，名字有点抽象，简单理解就是用户的信息是公开的，虽然是公开的，但还是需要授权码，只不过不需要用户介入，没有登录操作，直接用appid、appsecret获取访问令牌。
4.隐式许可，这个就更简单了，为了安全，appsecret和令牌都是第三方应用通过后端服务访问，不暴露出来，但是遇到那些只有前端的应用，appsecret就没有存在的必要了，直接用appid获取访问令牌。
简而言之，言而总之，OAuth 2.0就是定义了几种授权类型，围绕着用户、第三方应用和授权方展开。
以“用户用微信登录掘金”的场景为例，这中间涉及到两个应用，但只需要登录一次微信，用户将在微信的信息，这个过程就是授权，但是用户需要登录一次微信并同意授权给掘金即可，这中间的交互过程和安全问题就是OAuth 2.0所定义的授权标准
。
对于开发者而言，如果你是微信应用的开发者，那么涉及到OAuth 2.0的部分就是提供授权服务。授权服务要做的几个事情：
1.管理第三方应用（掘金），因为不可能把用户的信息授权给任意一个应用。
2.管理访问令牌，用户同意授权且验证第三方应用后，会发放访问令牌。这里要管理令牌的生成、续期、失效、验证等。
3.管理用户数据，要保障用户数据的安全。
如果你是掘金应用的开发者，那么涉及到OAuth 2.0的部分就是提供代理服务。代理服务要做的几个事情：
1.获取授权许可，去微信授权服务注册你的信息，拿到授权许可（appid、appsecret等）。
2.获取访问令牌，引导用户去授权服务获取访问令牌。
3.获取用户数据，带着访问令牌访问授权服务获取用户数据。
可以看到访问令牌其实是OAuth 2.0中的关键，拿到访问令牌也意味着整个授权过程完成。在OAuth 2.0标准中，又因为不同的授权场景存在不同授权类型或者是获取访问令牌的方式，这也是和OAuth 1.0的不同之处。四种授权类型：
1.授权码许可，授权的过程中涉及到第三方应用的前端页面和授权服务的交互，授权码起到重定向和安全的作用。授权服务验证用户密码后先返回授权码，最终通过授权码获取到访问令牌，也是安全性最高的一个。
2.资源拥有者凭据许可，名字有点长，简单理解就是第三方应用和授权服务属于一个主体，授权服务验证用户密码后直接给访问令牌，有点单点登录的意思。
3.客户端凭据许可，名字有点抽象，简单理解就是用户的信息是公开的，虽然是公开的，但还是需要授权码，只不过不需要用户介入，没有登录操作，直接用appid、appsecret获取访问令牌。
4.隐式许可，这个就更简单了，为了安全，appsecret和令牌都是第三方应用通过后端服务访问，不暴露出来，但是遇到那些只有前端的应用，appsecret就没有存在的必要了，直接用appid获取访问令牌。
简而言之，言而总之，OAuth 2.0就是定义了几种授权类型，围绕着用户、第三方应用和授权方展开。
展开
评论
1