OAuth2的实际应用中，最常见的就是“授权码模式”了。
微博是这种模式，微信也是这种模式。
总结来说，就是简单的二步：
- 1.获取code
- 2.根据code，去获取access_token
以微博为例（http://open.weibo.com/wiki/%E6%8E%88%E6%9D%83%E6%9C%BA%E5%88%B6%E8%AF%B4%E6%98%8E）：
假设我们开发一个网站（称为client；相对应的，微博就是server了），网站允许用户以微博账号登录，且需要读取用户的微博信息（账号、评论等等）。
显然，这过程中需要用户授权。
第一步：
- https://api.weibo.com/oauth2/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=YOUR_REGISTERED_REDIRECT_URI
第二步：
- https://api.weibo.com/oauth2/access_token?client_id=YOUR_CLIENT_ID&client_secret=YOUR_CLIENT_SECRET&grant_type=authorization_code&redirect_uri=YOUR_REGISTERED_REDIRECT_URI&code=CODE
这其中有几个问题：
1.获取code时，传递的二个变量（clent_id，redirect_url），没有一个是跟用户有关的，那微博怎么知道我们请求的是哪个用户的授权呢？
这个问题现在看来很可笑，但刚开始确实是蒙圈了。
其实，在第一步的URI发出后，是要求用户跳转到server端登录的。这很好理解，如果用户不登录，那你怎么知道是哪个用户呢，他又怎么给你授权呢？
此外，可以看到，第一步的URI，放在我们网站页面的任何位置都可以；它也不要求传递跟session相关的任何信息。
这个URI对应的页面是微博开发的，跟我们网站没关系。
事实上，这个URI可以直接拷贝到浏览器里发起请求；这个时候，是浏览器跟微博的一个交互，我们的网站是一无所知的。
那什么时候我们得知用户给我们授权了呢？
第一步URI的请求，浏览器得到的是一个http的重定向响应，这个重定向指向的就是我们的网站；此时浏览器向我们的网站发起请求：
类似于：
https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
站在我们网站后台程序的角度来看，我们是“忽然”（在此这前，它一无所知）收到一个code了，而这个code，是跟微博的一个用户一一对应的，我们拿这个code向微博发起请求，就能获得用户的授权，获得access_token，再发起另一请求，就可以获取用户信息了。
2.为什么在第一个URI请求发出后，微博的302重定向响应中，没有直接返回access_token，而是只返回一个code呢？
其实最初我的疑问更可笑：我想，为什么微博不直接返回access_token给我们网站呢？
这个问题的答案是，发起第一步的URI请求的，是浏览器！还记得前面我说的“我们的网站是一无所知”吗？此时微博是与浏览器在通信，而不是我们的网站，当然不能把参数传返回到我们网站了。
微博只能通过返回一个302响应，让浏览器重新向我们网站发起请求，把code传到我们网站来。
回到第二个问题。
该博客下有人是这样回答的：
- 为什么授权码模式需要这个授权码 当然是为了安全性 首先在OAuth体系中access_token是作为访问获取资源的唯一凭据 如果在AS授权完成之后 直接通过重定向传回access_token 那么HTTP 302不是安全的 Attacker有可能会获取到access_token 但是如果只返回Authorization code 就算别人获得了也没什么卵用 因为Authorization code不能获取到资源 在client向AS请求access_token的过程中 是通过HTTPS来保证安全的 而且获得access_token是需要client secret与Authorization code一起的 Attacker知道了Authorization code但并不知道client secret 同样也不能获得到access_token 所以client与AS是有责任保护好client secret的
- 获得了access_token之后 向RS发起请求 RS其实会与AS交互 来校验access_token 所以你想直接伪造一个access_token 那也是不ok的
- 突然想到漏说了一块 关于为什么不直接用HTTPS重定向回client
- 是因为不是所有client server都支持HTTPS~所以为了通用性 和安全性 才衍生出来这么一个Auth code
- 但是AS肯定是实现HTTPS的 所以在client向AS提起request 是木有问题的~
我自己的理解，是这样的：
直接返回access_token有可能被黑客拦截到，而拿到access_token就可以获得用户信息了，非常不安全。
那最容易想到的是，微博通过https返回access_token啊，https会对access_token加密，那不就可以了吗？
为什么这个方法不可行呢？
因为有可能我们的网站不支持https！站在微博的角度来看，千千万万的第三方网站，你要求每个网站都支持https，是不太现实的。
stackoverflow上的一个回答（http://stackoverflow.com/questions/13387698/why-is-there-an-authorization-code-flow-in-oauth2-when-implicit-flow-works-s）说这是“一个巨大的痛苦”：“a huge pain”。
那为什么返回code再去获取access_token就安全了呢？
因为这时候再去获取access_token，就是https请求了，发起方为我们的网站，接收方为微博，而微博作为OAuth server，肯定提供https。
但是，另一个问题来了，黑客拿到了code，它也向微博发起请求去获取access_token是不是就可以了呢？
也是不可以的。
因为向微博请求access_token时，还要带上我们网站的“密码”（client secret）。
这个密码，是我们网站在微博开放平台上注册时获得的（同时会得到一个client_id，这个值在第一步的URI里用到了）。
这一点在该博客没有提出来，最容易让人困惑。
3.为什么简化模式（implicit grant type）是可行的？
这个在stackoverflow有回答，前面也提到过：
http://stackoverflow.com/questions/13387698/why-is-there-an-authorization-code-flow-in-oauth2-when-implicit-flow-works-s
这就涉及到一个知识点：
浏览器不会把URL当中的“hash fragment”发给服务器。hash fragment是只留在浏览器的地址栏的，它可以被网页的js读取到：window.location.hash。
既然hash fragment没有发给服务器，那即使黑客拦截到请求，也获取不到它。
什么是hash fragment？就是URL当中#号后面的那一部分。
博客中的示例：
- HTTP/1.1 302 Found
- Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600
可以得知，“#access_token=2YotnFZFEjr1zCsicMWpAA”这一部分是留在浏览器这边的。
当浏览器接收到到该响应时，向http://example.com/cb发起请求，而后者的响应页面当中，应当有读取hash fragment的代码。
这样，client就拿到了access_token了。
解决了这三个问题，我本想到实际场景中抓包看看的，但遗憾的是，不管是蘑菇街还是聚美优品，这些允许以微博账号登录的网站，都只看到获取code那一步，没有看到获取access_token那一步。
或许改天有空可以自己在微博开放平台上注册一个应用来验证一下。
不过网上有人验证过微博的：
https://segmentfault.com/a/1190000000666685
此外还有一些关于微信OAuth2的实际例子：
http://www.cnblogs.com/txw1958/p/weixin71-oauth20.html
http://zeusjava.com/2015/04/22/wechat-get-userinfo/
都讲得比较详细。
zz:https://bylijinnan.iteye.com/blog/2277548