[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"content-oauth-in-mini-program":3,"$f31jzkzemrd68h":20},{"id":4,"type":5,"slug":6,"title":7,"date":8,"category":9,"tags":10,"body_markdown":13,"permalink":14,"excerpt_src":14,"media_type":14,"media_title":14,"media_author":14,"media_url":14,"rating":14,"layout":14,"pv":15,"admin_only":15,"created_at":16,"updated_at":16,"deleted_at":14,"status":17,"html":18,"cover":19},166,"article","oauth-in-mini-program","小程序接入OAuth","2016-12-29 09:17","web",[11,12],"小程序","OAuth","\n> 注：该方案实现后并未提审，所以只讨论技术可行性，不讨论是否合规是否过审的问题。\n\n这个问题按不同情况和不同解决方案大致有五条路可走：\n\n## 1 密码模式的OAuth\n\n简单来说，就是用户提供用户名和密码。可能有人会说：靠，这叫毛线的OAuth？对，我也是这么想的，但是以API规范著称的Github对非web应用就是给出的这样的方案：\n\n[GitHub Developer Guide](https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fdeveloper.github.com\u002Fv3\u002Foauth\u002F%23non-web-application-flow)\n\n> \"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.)\"\n\n翻译一下：\n\n> （非web流程）“使用HTTP Basic Auth（译注：即用户名和密码）来创建OAuth2 token，流程见XXX。使用这种方案时，不应该永久保存用户名和密码，用户要可以随时撤销授权。（如果你或者你的用户开户了两步验证，请确保你了解如何正确处理两步验证的情况。）”\n\n但，题主所说的微博、豆瓣是否支持这种模式，存疑。另外这种方式对用户来说非常不友好，毕竟要将密码交到第三方手中，如果是我来用，我是不会输的。\n\n## 2 直接使用密码登录\n\n靠？这又TMD叫什么OAuth？没错，这不是OAuth。但是对大部分使用OAuth的网站来说，都会让用户补充一下自己的用户名和密码。简单来说就是用户除了可以选择OAuth之外，还可以使用自己的用户名和密码登录。\n\n如果网站是一个很有节操的网站，并没有自己的用户名和密码，完全依赖第三方怎么办？\n\n简单啊，让用户补充一个不就好了？！\n\n## 3 授权码\n\n回想第二种方式为什么可行呢？当然你可以说这都不涉及OAuth了，当然可行了。\n\n我们也可以换个思路，上面第二种方法可行，是因为我们将OAuth的授权与网站本身进行了绑定，换句话说，当你输入用户名，我就能找到你是谁，你对应的OAuth信息是什么。\n\n那么，同样的思路，我们可以使用一个“授权码”（名字随意取，你高兴的话叫它“红包口令”都行），这个授权码和用户信息是绑定的，然后引导用户在小程序上输入授权码即可完成。\n\n从用户体验的角度来说，这个授权码不有太长，因为需要用户手工输入。\n\n从安全性来说，有一定隐患，所以一定要加上时效限制。\n\n## 4 授权码加强版-扫码\n\n在最近更新的一个版本中，小程序终于加上了扫码的能力。所以可以将上一种方案中的授权码做成一个二维码，让用户在小程序中扫描即可。\n\n## 5 unionId机制\n\n微信小程序支持微信开放平台已有的unionId机制。简单说把小程序当成一个平台，然后去[微信开放平台](https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fopen.weixin.qq.com\u002F)申请一个第三方网站登录。这样用户就有两套登录，一套在网站中，一套在小程序中。这两套机制中对同一个用户来说，unionId是相同的，因此可以直接将小程序中用户身份与网站身份对应起来。\n\n不过微信开放平台申请需要做一些认证，比较麻烦。\n\n## 小结\n\n严格来说，只有第一种是满足要求的，即完全依赖第三方登录。\n\n第二种依赖网站自有账号体系。后面三种都需要依赖微信的账号体系，然后将这个账号信息与已有用户进行绑定。\n\n另外这五种方案都需要后台配合，因为安全的OAuth流程中后台是不可以缺位的。\n",null,0,"2026-08-28 04:37:17","published","\u003Cblockquote>\n\u003Cp>注：该方案实现后并未提审，所以只讨论技术可行性，不讨论是否合规是否过审的问题。\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>这个问题按不同情况和不同解决方案大致有五条路可走：\u003C\u002Fp>\n\u003Ch2>1 密码模式的OAuth\u003C\u002Fh2>\n\u003Cp>简单来说，就是用户提供用户名和密码。可能有人会说：靠，这叫毛线的OAuth？对，我也是这么想的，但是以API规范著称的Github对非web应用就是给出的这样的方案：\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fdeveloper.github.com\u002Fv3\u002Foauth\u002F%23non-web-application-flow\">GitHub Developer Guide\u003C\u002Fa>\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>"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.)"\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>翻译一下：\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>（非web流程）“使用HTTP Basic Auth（译注：即用户名和密码）来创建OAuth2 token，流程见XXX。使用这种方案时，不应该永久保存用户名和密码，用户要可以随时撤销授权。（如果你或者你的用户开户了两步验证，请确保你了解如何正确处理两步验证的情况。）”\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>但，题主所说的微博、豆瓣是否支持这种模式，存疑。另外这种方式对用户来说非常不友好，毕竟要将密码交到第三方手中，如果是我来用，我是不会输的。\u003C\u002Fp>\n\u003Ch2>2 直接使用密码登录\u003C\u002Fh2>\n\u003Cp>靠？这又TMD叫什么OAuth？没错，这不是OAuth。但是对大部分使用OAuth的网站来说，都会让用户补充一下自己的用户名和密码。简单来说就是用户除了可以选择OAuth之外，还可以使用自己的用户名和密码登录。\u003C\u002Fp>\n\u003Cp>如果网站是一个很有节操的网站，并没有自己的用户名和密码，完全依赖第三方怎么办？\u003C\u002Fp>\n\u003Cp>简单啊，让用户补充一个不就好了？！\u003C\u002Fp>\n\u003Ch2>3 授权码\u003C\u002Fh2>\n\u003Cp>回想第二种方式为什么可行呢？当然你可以说这都不涉及OAuth了，当然可行了。\u003C\u002Fp>\n\u003Cp>我们也可以换个思路，上面第二种方法可行，是因为我们将OAuth的授权与网站本身进行了绑定，换句话说，当你输入用户名，我就能找到你是谁，你对应的OAuth信息是什么。\u003C\u002Fp>\n\u003Cp>那么，同样的思路，我们可以使用一个“授权码”（名字随意取，你高兴的话叫它“红包口令”都行），这个授权码和用户信息是绑定的，然后引导用户在小程序上输入授权码即可完成。\u003C\u002Fp>\n\u003Cp>从用户体验的角度来说，这个授权码不有太长，因为需要用户手工输入。\u003C\u002Fp>\n\u003Cp>从安全性来说，有一定隐患，所以一定要加上时效限制。\u003C\u002Fp>\n\u003Ch2>4 授权码加强版-扫码\u003C\u002Fh2>\n\u003Cp>在最近更新的一个版本中，小程序终于加上了扫码的能力。所以可以将上一种方案中的授权码做成一个二维码，让用户在小程序中扫描即可。\u003C\u002Fp>\n\u003Ch2>5 unionId机制\u003C\u002Fh2>\n\u003Cp>微信小程序支持微信开放平台已有的unionId机制。简单说把小程序当成一个平台，然后去\u003Ca href=\"https:\u002F\u002Flink.zhihu.com\u002F?target=https%3A\u002F\u002Fopen.weixin.qq.com\u002F\">微信开放平台\u003C\u002Fa>申请一个第三方网站登录。这样用户就有两套登录，一套在网站中，一套在小程序中。这两套机制中对同一个用户来说，unionId是相同的，因此可以直接将小程序中用户身份与网站身份对应起来。\u003C\u002Fp>\n\u003Cp>不过微信开放平台申请需要做一些认证，比较麻烦。\u003C\u002Fp>\n\u003Ch2>小结\u003C\u002Fh2>\n\u003Cp>严格来说，只有第一种是满足要求的，即完全依赖第三方登录。\u003C\u002Fp>\n\u003Cp>第二种依赖网站自有账号体系。后面三种都需要依赖微信的账号体系，然后将这个账号信息与已有用户进行绑定。\u003C\u002Fp>\n\u003Cp>另外这五种方案都需要后台配合，因为安全的OAuth流程中后台是不可以缺位的。\u003C\u002Fp>\n","",{"total":15,"totalRoots":15,"comments":21,"pv":15},[]]