移动应用的第三方平台登录在服务端的授权验证
如今，很多移动应用在做用户注册/登录的时候，为减少用户的交互成本，会考虑引入常用的第三方平台的开放登录授权来快速的将用户倒流到自己的平台中。在原来的第三方登录中，很多是采用基于 Web 的 Oauth 登录授权机制，在这种情况下，用户需要在 APP 弹出的网页中输入第三方平台的账号和密码进行登录，然后授权当前应用允许访问自己的账号。而现在更多的则采用的是所谓 SSO 授权机制，用户在点击第三方登录按钮后，应用会将用户引导至对应的第三方应用中，接下来只需点击授权按钮即可完成授权过程，大大增强了操作的便捷性和账号的安全性。但对于服务端开发者来说此时可能会发现，之前基于 Web 的 Oauth 登录授权会产生一个回调，服务器可以基于此来做授权验证。但在 SSO 这种机制下，回调会直接返回给应用本身而不经过服务器。这种时候应如何处理授权验证的问题呢？
OAuth2：客户端证书授权（Client Credentials）类型的开放授权
适应范围 认证服务器不提供像用户数据这样的重要资源，仅仅是有限的只读资源或者一些开放的API。例如使用了第三方的静态文件服务，如Google Storage或Amazon S3。这样，你的应用需要通过外部API调用并以应用本身而不是单个用户的身份来读取或修改这些资源。这样的场景就很适合使用客户端证书授权。 流程剖析 1. 用客户端证书交换访问令牌 应用程序需要向认证服务器申请访问令牌，而该请求则需要客户端证书进行认证。 假设现在我们正在折腾facebook，其认证URL为： https://graph.facebook.com/oauth/ac...
OAuth2：客户端验证授权（Resource Owner Password）类型的开放授权
适用范围 这种模式会直接将用户密码暴露给应用程序，因此应谨慎使用。一般说来，只有信任度极高的客户才应授权使用该模式，如官方移动应用、操作系统或高权限程序。 流程剖析 为了阐述该授权类型的认证过程，我们以Salesforce中基于REST的API为例进行说明。 1. 向用户索要认证信息 首先，我们必须得让用户将认证信息提供给应用程序。对于Salesforce来说，如果用户处于不可信的网络中时，除了需要输入用户名和密码外，还需要用户提供一个安全令牌作为用户的第三个输入。 2. 交换访问令牌 这里的访问令牌交换过程与授权码类型的验证授权（aut...
OAuth2：隐式授权（Implicit Grant）类型的开放授权
适用范围 仅需临时访问的场景 用户会定期在API提供者那里进行登录 OAuth客户端运行在浏览器中（Javascript、Flash等） 浏览器绝对可信，因为该类型可能会将访问令牌泄露给恶意用户或应用程序 流程剖析 1. 让用户明白所做的操作并请求认证 这一步与授权码认证模式中的操作类似，即当牵涉到OAuth认证时，应首先让用户明确该操作。然后将用户引导至授权页面。 该授权接口的URL会在开发者文档中给出，以谷歌为例： https://accounts.google.com/o/oauth2/auth 在请求该页面时还需附带...
OAuth2：授权码（Authorization Code）类型的开放授权
适用范围 需要得到长期授权 OAuth客户端是Web应用服务器 OAuth访问令牌不宜泄露给用户的环境 流程剖析 1. 让用户明白所做的操作并请求认证 当牵涉到OAuth认证时，首先应最好能更进一步的让用户知道该操作到底会发生什么。在用户确认之后，这时应用应将用户引导至OAuth认证页面。在该页面中，API提供者会向用户说明应用会授权访问用户数据。 该授权接口的URL会在开发者文档中给出，以谷歌为例： https://accounts.google.com/o/oauth2/auth 在请求该页面时还需附带几个参数： c...
OAuth2：Authorization Flows
OAuth2.0协议定义了用于获得授权的四种主要授权类型。Authorization code标准的Server授权模式，非常适合Server端的Web应用。一旦资源的拥有者授权访问他们的数据之后，他们将会被重定向到Web应用并在URL的查询参数中附带一个授权码（code）。在客户端里，该code用于请求访问令牌（access_token）。并且该令牌交换的过程是两个服务端之前完成的，防止其他人甚至是资源拥有者本人得到该令牌。另外，在该授权模式下可以通过refresh_token来刷新令牌以延长访问授权时间。Implicit Grant该模式是所有授权模式中最简单的一种，并为运行于浏览器...
