注:该方案实现后并未提审,所以只讨论技术可行性,不讨论是否合规是否过审的问题。

这个问题按不同情况和不同解决方案大致有五条路可走:

1 密码模式的OAuth

简单来说,就是用户提供用户名和密码。可能有人会说:靠,这叫毛线的OAuth?对,我也是这么想的,但是以API规范著称的Github对非web应用就是给出的这样的方案:

GitHub Developer Guide

“Use Basic Authentication to create an OAuth2 token using the interface below. With this technique, a username and password need not be stored permanently, and the user can revoke access at any time. (Make sure to understand how to work with two-factor authentication if you or your users have two-factor authentication enabled.)”

翻译一下:

(非web流程)“使用HTTP Basic Auth(译注:即用户名和密码)来创建OAuth2 token,流程见XXX。使用这种方案时,不应该永久保存用户名和密码,用户要可以随时撤销授权。(如果你或者你的用户开户了两步验证,请确保你了解如何正确处理两步验证的情况。)”

但,题主所说的微博、豆瓣是否支持这种模式,存疑。另外这种方式对用户来说非常不友好,毕竟要将密码交到第三方手中,如果是我来用,我是不会输的。

2 直接使用密码登录

靠?这又TMD叫什么OAuth?没错,这不是OAuth。但是对大部分使用OAuth的网站来说,都会让用户补充一下自己的用户名和密码。简单来说就是用户除了可以选择OAuth之外,还可以使用自己的用户名和密码登录。

如果网站是一个很有节操的网站,并没有自己的用户名和密码,完全依赖第三方怎么办?

简单啊,让用户补充一个不就好了?!

3 授权码

回想第二种方式为什么可行呢?当然你可以说这都不涉及OAuth了,当然可行了。

我们也可以换个思路,上面第二种方法可行,是因为我们将OAuth的授权与网站本身进行了绑定,换句话说,当你输入用户名,我就能找到你是谁,你对应的OAuth信息是什么。

那么,同样的思路,我们可以使用一个“授权码”(名字随意取,你高兴的话叫它“红包口令”都行),这个授权码和用户信息是绑定的,然后引导用户在小程序上输入授权码即可完成。

从用户体验的角度来说,这个授权码不有太长,因为需要用户手工输入。

从安全性来说,有一定隐患,所以一定要加上时效限制。

4 授权码加强版-扫码

在最近更新的一个版本中,小程序终于加上了扫码的能力。所以可以将上一种方案中的授权码做成一个二维码,让用户在小程序中扫描即可。

5 unionId机制

微信小程序支持微信开放平台已有的unionId机制。简单说把小程序当成一个平台,然后去微信开放平台申请一个第三方网站登录。这样用户就有两套登录,一套在网站中,一套在小程序中。这两套机制中对同一个用户来说,unionId是相同的,因此可以直接将小程序中用户身份与网站身份对应起来。

不过微信开放平台申请需要做一些认证,比较麻烦。

小结

严格来说,只有第一种是满足要求的,即完全依赖第三方登录。

第二种依赖网站自有账号体系。后面三种都需要依赖微信的账号体系,然后将这个账号信息与已有用户进行绑定。

另外这五种方案都需要后台配合,因为安全的OAuth流程中后台是不可以缺位的。