OAuth 2.0支持几种grant type，由于安全性不同，所以适用范围也不同。背景知识：

grant type	是否需要secret	是否出现授权界面
授权码模式（Authorization Code）	是	是
隐藏模式（Implicit）	否	是
密码模式（Password）	否	否
客户端证书模式（Client credentials）	是	否

secret需要保密，而常见的使用场景能否保密呢？如下：

使用场景	能否保密
web server site	能
web server api	能
web app(为避免混乱，下面称为js app)	不能
mobile app(Android, iOS等)	不能

可以看到app（js，Android, iOS等）无法保密，所以需要无secret的模式才行，也就是隐藏模式（Implicit）或密码模式（Password）。从安全性和可维护性角度考虑，Password模式是让用户直接输入密码，所以只提供给厂商自己app使用。第三方app只有隐藏模式（Implicit）可用，各家服务商的安全警告如下：

• Google : Installed apps are distributed to individual machines, and it is assumed that these apps cannot keep secrets. 
• Facebook : This app secret should never be included in client-side code or in binaries that could be decompiled. 

现在来看看常用的账号体系服务商支持的grant type。

账号体系	web支持Authorization Code	web支持Implicit	mobile sdk支持Implicit
Google		、
Facebook
Github		否	否，无sdk
QQ
微信		否	，
微博

可以看到Github只支持授权码模式，只能在web server上用，不支持app，请谨慎使用。不过由于github是生产力工具，使用github登录的第三方网站也都是生产力工具，比如、，只在web上用，也是可以理解的。

而微信不支持web Implicit，所以只支持web server，不支持web app，在纯API架构下，会带来混乱。

纯API架构是只开发一套api，同时支持各种app（js、Android、iOS），而没有了web server site。架构如图（）：

如果再使用OAuth Client即第三方登录，那它的纯API架构如下（）：

可以看到大部分公司做API仅供自家app使用，也就是私有API，用这种架构就可以了。多亏了API的HTTP server是自家的，所以也能把授权码模式加进去，用来支持github/微信，架构如下（）：

而如果API本身需要开放，就没了“自家的API”这个概念了，假设叫做api.example.com，那将变成双重OAuth架构（）：

可以想到会有两种场景：

• 第三方app没有自己的HTTP server，比如JS app，无法获取token。如果它们携带自己的app key去github/微信获取用户授权，跳转回JS app的地址获取code，交给api.example.com携带secret去github/微信验证，如果想通过的话，那此app key和secret要对应，即第三方app把自己的secret都告诉api.example.com才行，这样勉强可以用，但安全风险较大……如果第三方app携带example的app key去github/微信获取用户授权，跳转地址不对，无法获得code，此路不通。
• 第三方app有自己的HTTP server，则可以自己换取token，然后发给api.example.com即可。

本文首发地址：