a. about authing-js-sdk HOT 10 CLOSED

而观望现在，即使新浪是四大门户，有庞大的用户，其t.sina.com.cn仍然少不了一堆第三方登录链接，其中最明显的竟然是企鹅家的。现在在看企鹅家注册真的是和网易邮箱一样"繁琐"，而作为要统一全世界验证的Authing，竟然不支持QQ和微博的OAuth认证！
最重要的一点是用户数据的取用和隐私保护。
你看FB因为这个往外授权，虽然没正面刚官司，但是让国会轮番听证几个小时，欧盟现在更有史上最严的法案。
按照你们给出的解释，既想要
用户数据属于注册商，可以打消用户对于Authing官方可能会窃取用户信息的疑虑
还想要
基于分布式、点对点的特性，也可以使Authing的数据存储更加可靠。
接着是
Authing的商业目标，是成为全球最大的云端身份认证服务（甚至统一互联网所有的身份认证），使互联网变得更加安全。
我不说这是不是和OpenID的关系，但是鱼和熊掌不可兼得

from authing-js-sdk.

如果说有一个服务需要用户的信息比如生日，但是Authing的集中验证服务并不收集这玩意，当用户遇到第二个服务，还是这个样子，可能心里就会想这个产品就是个"复读机"一样，啥都干不了。
或者说一旦将数据收集，如果授权做的不好，就像安卓手机安装软件那样，用户还会觉得你他妈是怎么知道我的生日的？接着就是数据分析用途。即使很少的信息结合网络上其他来源的信息，也就能透明一个人，而这些信息真的是足够"有价值"，这足以算做侵犯隐私……
最后是功能性问题。不知道为何Authing非要和支付相关的东西产生联系，但是查看文档后发现并没有，而所谓生物验证更是啥都没有。这令我想起来当年的UCenter了，地球上仅此一家的独秀。
发现其实就是个超级SSO系统，还有就觉得目前的模型还要自己给OAuth的信息，简直不能忍！不能中转一下？这套流程就是一个夹心饼干一样把用户数据拱手让给别人别人获得了数据分析能力，自己还处处受限制一样

from authing-js-sdk.

谢谢你提了这么多建议，你所列举的问题正是我们想解决的。

针对你所提出的问题，我先一一作出答复。

1. 统一互联网身份这个问题，是我们的一个宏观想法，不一定要实现，但我们可以朝这个方向努力；
2. Authing的域名注册时间的确不到一年，一年前的这个时候，我的上一次创业刚刚失败，Authing
   是我在失败反思中产出的产品，正因为还不到一年，所以还有很多东西可以完善，而我们正在计划下一次的升级工作；
3. 据我所知，康盛创想的UCenter本来是为了连接discuz系统的（我也是UCenter的早期用户），跟我们的理念不太一样，首先需要明确的是Authing是一个基于云的服务。同时，我们也提供私有部署，当然私有部署也是需要付费的，我们认为任何一个产品，只有足够好的商业化才能提供更好的服务；
4. 关于QQ和微博的OAuth登录，目前囿于人力的确没有进行任何开发工作。采用微信和Github取决于我们早期的产品理念，一是Authing针对开发者群体，所以支持Github是必须的；二是假如开发者群体将Authing运用于其他方向，那么微信是一个非常大，也非常好的流量入口，这一点毋庸置疑；
5. 区块链和IPFS是我们下一步想要加入的功能，包括w3c官方也已经推出了WebID这个概念，我不太理解这个和OpenID鱼和熊掌的关系在哪；
6. 关于OAuth信息的问题，如果你有更好的不侵犯用户OAuth隐私的方案，欢迎提出来，我们目前没有想到更好的不提供OAuth信息进行OAuth登录的方案。

最后，再说一下。

做Authing的初衷，是为了解决我自己的问题，当然如果能提供给其他人使用也是最好的。采用云，是因为云方便。国内的云计算事业刚起步时，企业普遍不接受，而现在阿里云已经成了全球第三大云计算厂商。我们相信，云计算这个产业也和互联网服务一样，是细分化发展的。

from authing-js-sdk.

如果你有更多想法，我们可以加个微信交个朋友。

from authing-js-sdk.

你好，我刚刚看见GitHub的邮件，被网易企业邮扔垃圾桶了，所以过了一个星期才回复

我也是UCenter的早期用户，当年这款产品最开始就是给UCenterHome和Discuz两款产品用的，后来是有了UCenter Client和Server分离，再后来就有了Dedecms等更多的接入

我的认为是，在Authing的和GitHub与微信的对接过程中，本身就是一个OAuth的过程，如下所示https://docs.authing.cn/#/oauth/oauth
所以在以下链接中的图片，我真的很想知道Authing这款产品是搭桥还是分析数据
https://docs.authing.cn/#/quick_start/jwt
根据你们Git上的readme.md，目前还有很多没有实现。
我这几天仔细看了一下Authing的后台，首先是用户数据全部保存在你们的服务器，其次OAuth功能竟然要自己填这些！
根据Git上所说
Authing拥有4个模块，这四个模块支撑了Authing的所有流量，分别是：用户服务（Users）、OAuth服务（OAuth）、邮件服务（Emails）和支付服务（Pay）。
后台真的很Normal，就是用户添加呀，管理呀，然后发邮件，接入OAuth，这和所有的后台面板比如UCenter，WindsFramework，FastAdmin是一样的。
所以我觉得可能重要的，是数据分析能力和接入速度。正好，如官网所说
7行代码接入整套用户系统
的确比其它一堆认证系统包括Laravel和ThinkPHP框架自带的都好很多很多，经试用，这个注册过程是简直不能太简便，简便到没有任何真人认证，至少是官网，那服务器不是随随便便刷爆吗？接着是官网真的没有明显的退出登录，退出我都是靠删cookies。
在一般用户体验来说，简直好到不行，但是对于真的接入了你们的普通网站，也不必担心，刷爆的不是自己的数据库。但是真的要是论坛和新闻资讯类网站，那不还得成筛子？本来DZ的反灌水已经做很大努力了，甚至不惜在QQ和微信登陆后还要你再点一遍以注册新账户，虽说是DZ最弱智的插件，不过要是QQ登录一下就转正发帖，那么万一敏感词事件发生，就根本停不下来！
接入Authing，我觉得一个登录框和一套的管理系统不难，更多是做到7行这样的简便，其次是为了安全，这里不是指通信安全，因为JWT和https已经十分安全，可毕竟是云端认证，总比本地认证有更多的机会，应该可以做到对某些假人拦截，对大多数风险进行控制，还有目前对更广泛的数据接入以及更多的SDK，这应该是你们目前真正需要的

from authing-js-sdk.

对了，目前我的摸索对于你们的支付服务更是一无所知，所以想问这方面是没开发完还是说内测中？
另外Authing目前的后台是针对开发者型的，目前是否有考虑修复一下GitHub登录不进去的bug？
还有一点就是，能否做到一个用户，多个站点。尽可能做到一个账户？
我认为在传统情况下，一般用户都会认为不同网站都有不同账户，而Authing如果想做到统一，不能让同一个人在不同的但是都接入Authing的网站再注册多个账户

from authing-js-sdk.

@NciYuan-Net

你好，目前还未发现Github登录不进去的问题，能否提供下你的Github账号和错误信息，我们好看一下是什么问题。
一个用户多个站点这个功能是有的，一个账户可以创建多个应用，这多个应用就是多个账户。

支付服务其实是我们的内部按量计费服务，对用户是不可感知的。

from authing-js-sdk.

还有就是我们的后台，目前还在继续更新迭代，其实很多功能，表面看上去比较简单，其实没那么简单的。

from authing-js-sdk.

退出功能点击头像会有下拉菜单

from authing-js-sdk.

OAuth服务填写必要信息是必不可少的 : )

from authing-js-sdk.