控制台
authing blog banner
查看文章
Authing 7 月小报 | 上线身份供应、支持多种加密算法、新增 WordPress、Strapi、北森等主流应用集成合作
7 月亮点速览 1. Authing 产品优化 应用市场新增:WoldPress、Slack、Seafile、 阿里云国际区、AWS 国际区、Discourse、 Jenkins、kibana、Strapi、销售易、Metabase、纷享销客、Adobe、Expensify、轻流、Strapi、每刻报销、北森、Sonarqube、Bitbucket、Sentry、Jamf,以及集成应用的教程指南。 身份供应上线:管理员可以通过应用市场,设置第三方集成应用,向下游应用灵活地自定义提供用户身份供应。当配置完成后,在该用户池内对于用户的增删改,都会实时地同步到下游已配置身份供应的应用平台上。以下应用已支持配置身份供应:阿里云、飞书、北森、 Google、Jira、 Zoom。 应用面板功能优化:Authing 应用面板的主要功能是展示企业所需的各类应用,它对企业的意义在于为员工提供了一个保证信息安全且提高工作效率的单点登录集合地。 控制台功能优化:上线密码轮换策略配置功能,客户可以设置用户池内的用户的密码强制定期更新,客户可以设置用户池内的用户的密码再一定周期内不能重复使用。上线 JWE ID Token 加密配置能力,支持多种加密算法。 2. 开发者活动 公号输入:资料,下载演讲 PPT   · 7月29日,ISC 2021 第九届互联网安全大会:主题演讲《以身份为基石的零信任网络,让互联网不再有隐秘的角落》 · 7月24日,Authing & 又拍云高性能服务最佳实践沙龙:主题演讲《亿级流量系统架构的演进之路》 · 7月17日,Authing & 七牛云云原生基础设施落地实践沙龙:主题演讲《Authing 身份云的云原生探索与实践》 · 7月17日,Authing & 声网前端专场巡回沙龙:主题演讲《用 Canvas 写游戏,兴趣使然地编程》
ISC 2021 活动现场干货|以身份为基石的零信任网络(文末下载 PPT)
7月27-29日,由中国互联网协会、360 互联网安全中心等多家机构联合主办的 ISC 2021 第九届互联网安全大会在北京国家会议中心拉开巨幕,作为身份云行业领先的零信任解决方案提供商, Authing 受邀出席本次大会,并分享《以身份为基石的零信任网络,让互联网不再有隐秘的角落》的主题演讲。     随着现在世界越来越多地采用移动和云技术,也就有越来越多的工作在企业安全网络之外完成,企业的敏感资产不再有一堵围墙:员工、合作伙伴和供应商都可以跨传统边界访问企业数据。 安全领域的这种转变导致了零信任模型的诞生。Gartner 在其 2017 年的 CARTA 框架中,特意强调零信任不仅需要更加关注入口的认证和授权,还要通过自适应的、基于风险的评估来识别潜在访问威胁,持续贯穿用户体验。Forrester Reserch 公司将单点登录 (SSO) 等功能称为一项关键功能,并指出多重身份验证 (MFA) “可成倍地减少访问威胁”。 虽然技术演变,但是零信任核心概念依旧保持不变:在当今的安全环境中,它不再与网络有关,而是与访问您系统的人员以及对这些人的访问控制有关。   因此,要实现零信任网络安全体系结构,身份和访问管理应该是组织最先开始的核心技术。我们需要为不同的用户启用安全访问,无论他们的位置、设备和网络。这也就是 Authing 身份云在零信任中的用武之地,企业可以利用 Authing 作为现在和未来成功的零信任计划的基础。 5个步骤实现无边界安全 01. 在用户身份中建立信任 第一个步骤是将 MFA 部署到所有应用程序和用户设备中。这之后你会得到一份完整的用户和设备列表,对接下来的步骤很有帮助。 部署 MFA 是一个可以让用户轻松过渡到零信任模式的很好方式。同时也会产生一些挑战,比如管理员需要时间来适应无边界安全的理念,用户样需要时间来习惯每次登录时采取额外的安全措施。 02. 用户设备和行为可视化 当已经有了一套系统来确定是否信任用户的身份,接下来要做的是了解他们访问应用程序的设备。 这一步的核心是创建并维护企业和个人所有设备的列表。这能让你能看到所有设备相关的情况,也能帮你捕捉到有关这些设备安全性的关键信息。这非常重要,因为它可以帮你衡量与用户和设备相关的安全⻛险,从而更好地掌握到底是什么类型的设备在访问应用。  03. 确保用户设备的可信度 前面,我们已经谈到了零信任如何基于多个属性来管理安全,在新的范式中,许多关键属性告诉你更多关于请求访问的端点设备的信息。对于第三步, 你将定义和审查端点设备的特征,这些特征将在每次登录时得到交叉验证。  例如,许多企业使用零信任模型,以两种关键方式建立设备的可信度。 1. 确认它曾被授予过访问权限   2. 强制要求它满足安全规定(如限制设备操作系统的最低版本等)   了解设备是否由企业管理也很重要。    用户和设备的 "可信度判定 "永远在访问应用程序之前。例如,如果用户拥有正确的凭证,但试图从一个在不符合规定的设备登录他们的工作邮箱, 他们仍然会被拒绝访问。   这套策略也被叫做 PBAC (基于策略的权限控制)。 04. 执行基于风险的自适应的访问策略 接下来,需要创建与用户和设备双重相关的安全策略。 例如,如果一个用户在上午 9 点从家里登录检查电子邮件,这可以被认为是典型的行为,是可以被授权的。但如果同一个用户在周末登录,并在 Salesforce 中检查他们以前没有访问过的客户数据,那就可以认为是异常的,基于风险的模型可以捕捉到这一点。  而且由于与用户及其设备相关的⻛险可能会在访问尝试之间发生变化,例如,用户的设备软件过时了,你的访问策略也必须适应不断变化的条件,以保持可接受的⻛险水平。  05. 安全连接所有应用 一旦用户验证了自己的身份和设备的有效性,并且验证了用户-设备策略,用户就可以在其设备和企业的应用程序之间建立安全连接。  首先将零信任模型推广到最高⻛险的应用程序。企业最终需要保护所有应用程序,所以从最重要的应用程序开始,然后逐级下降。需要注意的是,与应用程序的连接并不是根据访问来源的网络来推断是否信任,而是验证用户和设备。 传统身份认证管理(IAM)的困境 · 系统结构复杂耗时耗资 · 扩展性差难以集成新系统 · 无法满足分布式身份与权限管理的诉求 · 安全保护机制单一数据泄露风险高 · 无法应对组织身份和应用快速增长的诉求     Authing 现代化的身份云平台 昨天:身份是网络的一部分,网络本身是边界 今天:传统边界正在消失,身份是新的边界 明天:以身份为中心的零信任网络,Authing 作为身份标准和通用平台 身份是零信任网络安全的基础,Authing 身份云平台经过严肃、精心的设计重构,是以开发者为中心,独立的、中立的、安全的全场景身份云平台,最大化地赋能开发者释放生产力,帮助企业更好地面对各种复杂的业务生态与变化。 Authing 与您携手,打破传统边界,连接人与应用,让互联网没有「隐蔽的角落」。 扫一扫关注公众号 输入:零信任 ,获取完整版演讲 PPT
Authing 身份云的云原生探索与实践|干货
7月17日,「ECUG Meetup 第 2 期」活动中,Authing CTO 尚斯年带来了以《Authing 身份云的云原生探索与实践》为主题的大量干货分享,本文是对分享内容的整理。 本文长达 7000 余字,以下为正文: 01 Authing 就是身份云 很多人不知道 Authing 是什么,这里我用一句话概括:Authing 就是“身份云”,我们希望将身份做成一种基础设施放到云平台上。 我们为什么做这件事情?是因为发现互联网发展过程中有个脉络。     2000 年初网易、新浪、搜狐等平台的兴起出现了“内容在线”;接着出现了“沟通在线”,例如微信、QQ;之后出现了“娱乐在线”,再往后就是“交易在线”,比如电商、京东。 互联网发展到现在,办公场景逐渐在线化。钉钉、企业微信等产品已经融入到我们日常办公生活中——人的身份可以贯穿互联网的生活。 软件发展初期,身份是其很重要的一部分,比如你买了 SAP,需要注册帐号才能正常使用,但是不同应用的帐号体系但是相互之间是割裂的;软件发展至今,身份识别已经变成了独立的平台,例如 Google、Microsoft、Office365、Facebook 帐号等,其中 Facebook 的用户可以通过帐号登录多个不同的业务系统或者平台,实现这一切都是基于 OpenID 的身份互通的协议。   未来必须要有个统一的或者中心化的平台来解决所有身份问题,这同样也是我们的愿景。Authing 作为一个通用平台,既能支持云应用、IoT 应用;也能支持设备、私有云平台以及不同的组织;不仅如此,我们还能支持统一的面向私有云、公有云、混合云身份解决方案。 软件发展初期,“身份是软件一部分”的方案由于成本和复杂性的限制。如今,我们使用Facebook 的社交账户去登录其他平台。未来我们希望看到通过 Authing 这种统一的身份平台去连接任何组织和任何应用。 设计初期,从最简单的登录框开始分析,我们发现现存的应用登录框的设计其实非常简单,有用户名、密码即可登录,但这种方式存在以下问题: 1) 不同系统需要重复登录;2) 需要记住大量帐户和密码,不同的应用系统之间的帐号体系不通用的;3) 登录方式单一,基本是用户名、密码或者手机验证码,且不支持较先进的登录方式,比如人脸、指纹、生物识别;4) 安全保障机制单一,通过密码对人的身份校验;5) 没有用户自助服务,仅支持管理员统一管理;6) 用户自身关联性较少;7) 缺乏自定义界面;8) 用户补全信息功能无法使用。 我们的目标是满足以前用户需要但没有实现的需求:1) 可以切换显示语言;2) 当用户遇到问题时可以随时向平台反馈;3) 支持不同的登录方式,也支持普通登录、扫码登录等等。 下图是 Authing 平台的登录框页面:   登录框虽然只是我们做这件事的冰山一角,但在冰山之下却暗含很多能力,包括认证、授权和用户目录管理等等。企业在做内部组织管理的时候也面临诸多挑战: 1) 通过企业微信、钉钉这种单点登录方式的系统,此业务系统是与三方的 SaaS 软件集成的;2) 面向 CRM 销售的业务系统,它的组织是面向单独财资组织,跟企业的主组织并不一样;3) 跨国公司,集团公司和分公司的组织结构,这种场景下的组织融合问题是很有挑战的;4) 用户管理和访问策略。 我们了解到从事研发的同学都知道 RBAC 访问策略,这是一种相对简单的访问控制。传统的 RBAC 缺乏风控识别能力,所以我们希望 Authing 平台的访问策略能得以改善,在配置权限时不仅能实现基于规则的权限配置,还能实现基于用户行为风控策略。 企业员工在入职时需要找管理员分配员工帐号,如果不同业务系统需要找不同的管理员分配帐号,这样就会让入职流程变得复杂。虽然大家在入职时或许也可以接受这种复杂操作,但员工离职时会出现非常大的安全风险。所以我们针对这一问题设计了一套身份供给和反供给方案,当员工入职之后会自动向下游系统创建账号,当员工离职之后会自动收回账号。 Authing 平台从登录框入手,做一整套围绕身份的服务。 我们从两个角色的角度来分析,一个是用户身份,另一个是员工身份,这两个角色概念是不一样的。用户身份更偏向于面向 ToC 的场景,例如电商、社交;员工身份面向是内部组织管理场景。我们希望 Authing 平台既能为企业内部提升效率,也可以成功帮助企业实现业务增长。我们可以通过提供用户画像来管理用户身份,使得企业可以从用户身份中获取更多信息并实现运营效率的提升。目前 Authing 平台客户有安永、THERAGUN 这样的外企,有中国石油、高等教育出版社这样的国企,最近也做了一些车企项目。 下图是我们的发展历程,我们是非常年轻的公司,2019 年成立,到现在是 2 年时间,去年完成了三轮融资。     02 向云而生,IAM 到 IDaaS 回到我们这次主题,关于云原生我们做了哪些工作?我们的主题是“向云而生,IAM 到 IDaaS”。首先我们先谈IDaaS、IAM的概念和区别。 IAM 是“Identity and Access Management ”的缩写,即“身份识别与访问管理”。IAM 是一套通过全面建立和维护数字身份,并提供有效地、安全地 IT 资源访问的业务流程和管理手段,从而实现组织信息资产统一的身份认证、身份授权和身份数据的集中管理与审计。 通俗地讲:IAM 是让合适的人在恰当的时间通过统一的方式访问授权的信息资产,提供集中式的数字身份管理、认证、授权、审计的平台。 我们为什么还需要 IDaaS?是因为传统的 IAM 有几点不足:  1)运营能力弱,传统 IAM 账号中心的运营能力较弱,难以满足大型组织在业务方面的需求,例如,筛选出六个月内未登录过的用户,并向他们发送营销短信;或找到那些高频使用的用户并交由客户经理转化商机。 2)缺乏伸缩性和扩展性,当企业的用户量不断上升时,用户系统承载的压力也会不断增加,传统的 IAM 主要靠堆积服务器和设置负载均衡来优化,但登录失败的次数总是随着用户量的增长而增长,这对企业和用户来说都是灾难。 3)运维费用高,大多数 IAM 专家难以雇佣并且费用高昂。而且当企业计划将内部员工训练成专家时,他们面临着将训练好的员工流失到咨询公司或竞争对手那边。 4)安全性欠佳,数据资产正在逐渐超越实体资产成为企业最有价值的核心。而针对数据资产的盗窃和攻击也呈不断上升趋势。传统的 IAM 在本地构建,难以保障混合云环境下的企业安全,权限管理颗粒度较粗,访问控制策略单一。 5)难以更新换代,大多数企业的 IAM 系统需要消耗巨大的人力物力去更新换代,而当企业耗尽千辛万苦将系统更新好了之后,市面上又出现了新的技术和系统。  IDaaS 是在 IAM 基础上加上了云计算,相比 IAM 增加很多优势:   1)多种认证与访问控制策略、灵活高效;2)基于云原生架构、天然适应,海量数据存储;3)多维度保障数据安全;4)在 IAM 的基础上实现全面拓展。 所以我们的能力是一种可复用的身份基础设施,是以身份作为基础设施的一种来看待我们这个产品。 从云计算角度看 IDaaS,我们是在哪一层?我们都知道云计算有 IaaS、PaaS 和 SaaS 三层,我们更多是 PaaS 和 SaaS 之上的一层,面向应用和用户侧。近年来联网的设备爆炸性增长,企业级的数据量也在增长,企业所用到的应用也在增长,我们是在这之上提供了统一的组件,它包含登录、注册、身份鉴权、用户交互这些功能,在 PaaS 和 IaaS 之上 SaaS 层提供了云的统一身份管理解决方案。 我们面对客户有不同的交付环境,私有云、混合云、公有云,我们是如何交付我们的产品?在这之上我们提出了“云中立”的概念,我们的产品交付在用户任何云环境上。 比如这个客户只 30 个人,没有必要太复杂架构,在我们平台一个 SQLite 就可以跑起来。如果这个用户是 2000-10000 人的规模,需要一定可靠性、安全性的保障。又或者是私有化方案,我们可以使用开源组建进行替换。我们开发者用户或者中小企业说没有必要私有化部署,直接用公有云平台,我们是在公有云之上提供公有云的解决方案和组件,这些东西都是可以替换的,我们做一套适配层 Adapter,可以在任何云平台上部署我们的产品。我们的产品已经部署在腾讯云、阿里云、AWS、Google 和用户的私有云上。  我们在公有云上也有一套高可用的架构设计,这也是比较经典的一套,就是多 Region 的概念。           我们的平台是架设在 AWS 中国区,在一个 Region 中使用多个可用区,使用负载均衡,跨可用区构建双集群和数据库。当一个可用区出现故障后,我们可以立刻启动另一个可用区。最近我们也有客户采用跨国方案,我们也会在 AWS 数据库上构建 Global Database,各个国家之间就近接入。大致的思路是一样的,去构建多 Region 高可用的技术架构。 Kubernetes 在我们创立这家公司时也成为了一个事实的标准,所以我们在构建时是面向 Kubernetes 的。Kubernetes 除了是本地化部署,也可以是云上部署。小规模的本地化部署比较简单,可以用 Docker Compose 这样的方式,我们在私有云交付的时候可以直接交付一套 Kubernetes 的编排。 在 Kubernetes 之上构建一套多租户方案,很多企业不同的业务系统希望有不同相互隔离的身份平台,比如之前有个金融行业客户,它需要华北区是一套独立的身份平台,分为开发环境、线上环境,如何用统一的配置管理平台解决这些问题?所以我们在 Kubernetes 之上构建了一套多租户方案,我们在基于 Kubernetes 的 API 实现快速创建一组或多组 Authing 服务。 03 面向服务的认证与授权 刚才提到身份时基本提到的是面向人的身份,我们现在聊一下机器间的认证与授权。在微服务架构,尤其云原生倡导微服务时,如何进行服务治理?服务之间是如何完成认证和授权的?有没有统一的方案? 在我们的平台,基于 OpenID 的标准协议实现 M2M 的身份授权解决方案,M2M 是 Machine-to-Machine 的缩写,指的是服务之间的认证与授权。举个简单的例子,如果你是个外包商,需要将业务 API 提供给业务方,几个外包商给客户开发一个大屏的数据展示,你希望将某些非核心的 API 访问授权给外包商,外包商完成非核心部分应用开发需要授权,过程中不需要用户参与,只需要确定来访者是哪些外包商以及哪些接口。   授权就像左图的服务 A 调用服务 B 和服务 C,B 允许服务 A 调用时,有让服务 A 调用服务 B 的权限,C 没有这样的权限。我们发现这种模式有一个问题,就是对代码有侵入性和耦合性,像服务 B 时、服务 C 有个专门认证模块,去判断服务 A 是否能调用,这些与业务无关的认证模块很有必要,我们可以在中间加一个统一的中间件 Authing,所有的认证控制都是通过 Authing。 讲到这里,很多对云原生比较了解的同学就知道我下面要讲了什么,就是 Service Mesh 概念,Service Mesh 是可以天生支持服务间的相互控制,包括流量控制、数据控制,像服务之间的认证与授权。   04 开发者友好的身份云 我们做身份云平台之中非常关注开发者体验,这也是云原生很重要一个概念。 我们产品迭代有个概念叫「API First」,将所有能力 API 化提供给开发者。我们的目标是开发者完全可以基于我们平台的 API 做一个和我们平台一模一样的产品。用户可以通过不同设备访问我们平台全量的 API。   这是面向开发者最大的价值,在 CNCF2020 开发者现状报告中,现在全球有超过 470 万开发者在使用云原生技术,占全部后端开发者的 36%。开发者已经成为云原生变革最主要的推动力量。 我们在平台中提供全量的 SDK 和 API,后端的像 java、Python、.NET,前端的像 JavaScript,安卓、iOS,还有跨端的 React Native、Flutter。希望 API First 的体系架构是一种设计方法,它以 API 为中心,我们认为 API 开发出来的应用就像乐高积木一样模块化,是可复用可扩展的。面向 API 就是面向开发者,可以更好将身份服务集成在开发者和企业的业务当中。 在 API 之上我们提出了 Hyper Component 的概念。经常我们把 API 交付给客户时,客户说用你的 API 要进行二次开发,还要封装组件。我们将登录框做成组件的形式,只需要几行代码就可以嵌入到我们的应用系统平台之上。考虑到前端有不同的框架,我们也面向不同前端框架提供统一的组件化方案,同时支持 React、Angular 和 Vue,完全可以集成在企业和开发者自己的平台之中。 虽然我们提供了 API、提供了组件,用户的诉求是千变万化的。举几个用户常见的想法:想要获取用户注册来源;想要在系统维护期间,禁止用户访问登录;注册之后,希望自动发送钉钉、企业、飞书信息;希望在白名单的用户才可以访问;希望收到邀请的用户才可以访问。... 用户的诉求无穷无尽,有没有一种方式尽可能满足用户的诉求? 我们还创建了「Authing Pipeline」的概念。Authing Pipeline 是一组运行在云端的用户自定义 JavaScript 代码,可以让开发者扩展、自定义 Authing 能力。在认证身份流之中,登录、注册前后都可以插入钩子执行用户定义的函数。所以身份服务是一种统一平台,面向用户不同场景,去适应用户的场景。  还有一个问题是用户担心数据的安全性,尤其是外企的用户经常说你们的数据是不是被政府所监控?我们核心业务数据放在你这不安全?所以我们提供了自定义数据库的功能,用户的数据完全由用户做主,企业或开发者的数据并不存储在 Authing 上,在每次认证时通过调用脚本访问自身平台的数据,这种方式有一定的性能损耗,但是安全性更好,我们提供了这样一个自定义数据库的连接。  我们有两种数据库连接模式。一种是惰性数据迁移模式,每次用户访问自身数据库,完成信息比对之后将数据惰性迁移到平台;还有一种完全使用你自己的数据库,我们平台只完成用户身份认证,不存储任何数据。这种模式是通过脚本,脚本是 JavaScript,可以连接像 MangoDB、MySQL 数据库等等。   上图是完整的技术方案,在用户完成认证的时候,我们进行函数计算,函数计算也是通过后台上传的,像 AWS 或者阿里云、腾讯的云函数计算,用户通过自身云函数计算访问自身数据库完成数据接入。 这个方式也有问题: 1)构建和上传速度慢、用户体验差;2)有网络通信时间延迟,登录等待时间长;3)函数冷启动问题,虽然现在各大平台将函数的冷启动基本解决了,面向温启动,几十毫秒之内能够启动,但是对用户来讲也是没必要的损失;4)和我们云平台耦合性比较重,私有化部署时无法实现快速接入。 我们找到了 Safeify 的 Javascript 沙箱解决方案,相比之前其他沙箱模式这个方案提供更好的资源隔离能力。这种沙箱可以通过进程池管理调度沙箱进程,处理的数据和结果,还有公开给沙箱的方法,针对沙箱进程进行 CPU 和内存配额限制。它的核心是沙箱运行在不同进程,然后完成任务。 05 Authing 快速发展背后的云原生技术 刚才讲了提供给开发者的各种方式和好处,也讲讲基于云原生技术,我们是如何快速发展的。我们在 2 年内完成快速发展,去年完成第三轮融资,我们平台有千万级的客户,我们是如何做到这些的呢? 第一点,构建基础设施及代码方案。使用 Terraform 编排。业务上云对 IT 基础设施的管理提出了更苛刻的要求,我们需要: 1)更好的系统效能:及时了解相关领域而规避了风险,确保了合规和 IT 基础设施的安全;2)更快的速度:在今天,软件交付/更新的速度被认为是成功背后最重要的因素之一,需要保证基础设施的高效迭代;3)高效的变更管理:在部署到生产环境之前,代码常常被修改和测试。基础设施即代码确保了在不同设备、平台和系统中实现更安全和高效的变更管理;4)可扩展的基础设施:硬件的虚拟化使得在需要时增加、替换和扩展资源。 面对这个问题,我们使用了 Terraform 这个编排。给客户交付时,如果客户希望部署在阿里云平台,也基于 Terraform 进行快速基础设施搭建,当用户有基础设施和环境变更时,可以快速完成底层基础设施的变更,而且每次变更都是有迹可寻的。  第二,持续交付。云原生系统之中应该关注用户交付能力。并没关注以下两点:  1)概念和操作尽可能简单,每一个成员无论技术水平高低,都可以可以快速理解 CICD 流程并将自己代码发布到不同环境。 2)最小适用,如无必要勿需增实体,用尽可能简单的组件完成代码集成和上线交付。发展之是,我们希望所有的东西尽可能简单,一个组件完成交付,就不会扩大更多组件,保证系统的复杂性。 第三,日志与监控。我们是一个 SaaS 平台,保证 7×24 小时高可用,有任何线上问题要及时暴露出来,这张图展示的是我们基于 Prometheus 的监控与报警解决方案。   Q & A Q:我想问一下单点登陆在一个登陆之后,在其他平台上也能够实现完成登陆的登陆态。它如果实现登陆之后,减少社会化登陆的过程,那登陆好之后如果有一个点下线了,你们是怎么进行通知的? 尚斯年:第一点,单点登陆是我们模块之中一个,但并不是我们全部,还有像用户目录、融合等等。一般登陆通过 token 的方式是没有登陆信息的,登陆之后向业务系统推送消息,让它把自身的给删除掉。 Q:退出登陆之后有没有在线统计或者系统检测?一个点退出之后,另外一个点能不能主动得到消息?还是等下一次有活的时候它自动下线?里面有在线用户时长统计? 尚斯年:不是,我们是直接给它发一个消息,它通过这个退出的消息,比如它在系统 A 退出了,我会给 B、C、D 消息,让它把 B、C、D 退出了。在线用户时长统计是有的,这就是我们增加运营的能力。 Q:如果我们的内部系统接入,但是内部系统还是有些权限的,我们是不是基于你们的平台才能做二次开发? 尚斯年:一些细粒度的权限需要通过 API、SDK 接入的,还有一种方式是在网端这一层,所有的权限校验都在网端,对象后面是透明的使用方式。 Q:你们产品的愿景是说更像一个 ToC 的愿景,但是你们的应用是个 ToB 的应用,这中间是什么关系? 尚斯年:很多厂商是纯做 ToB 的,有很多厂商是纯做 ToC 的。我们是国内首家做 CIM 和 EIM 两种场景,E 就是面向企业的,身份是一种基础设施,拿基础设施用的时候不应该考虑它是 C 和 E,就像你用 Kubernetes、MySQL 时不会考虑 Kubernetes 在 C 的场景还是 E 的场景,我们是两套兼容这两个场景的解决方案。 Q:社区有一些邦联式数据,你们也支持邦联式的?还是全套是你们的? 尚斯年:支持邦联式的,身份联邦也是支持的,可以互相传递身份的认证。
刚刚,WordPress 上线 Authing 应用市场
WordPress 是全球最大的内容管理系统,用户可以在任何支持 PHP 和 MySQL 数据库的服务器上架设网站,并轻松地管理内容。这套系统因易用性、易扩展性(插件、模板、二次开发)、功能强大、美观、搜索引擎友好而著称。全球大型的新闻社和博客中有一半都在使用 WordPress,如纽约时报博客、Techcrunch、CNN 博客、连线杂志、路透社博客、华尔街日报博客、中国数字时代等。 此次 WordPress 上线,是作为 Authing 应用市场集成资源的又一重要补充,更好地为用户提供单点登录的服务。     Authing 提供了一个保证信息安全且提高工作效率的登录体验,用户可以选择 Authing 应用面板「Authing 应用面板」正式发布,助力企业提高员工办公效率,也可以选择企业微信、飞书等作为入口。 事实上,Authing 已经逐步聚齐市场上所有的主流应用,主要原因之一是单点登录正在受到广泛的重视。 首先,大部分企业的业务正在向云端迁移,应用数和用户数双增长;其次,劳动力更加流动和灵活,员工或合作伙伴远程访问组织内的应用程序变得更加普遍。 Authing 对各类应用的单点登录(SSO)集成是基于安全断言标记语言 (SAML) 和 Authing 自研的安全身份验证 (Authing Secure Authentication) 而实现的。                                                                      (应用市场-部分展示)   实施单点登录( SSO ),企业可以严格控制访问权限,降低弱密码及身份分散带来的安全漏洞问题,其用户还可以通过单一身份验证无缝访问所有的应用程序,提高登录体验,并且为集中自动化的处理授权和用户生命周期管理打下基础,更有助于合规性,这无疑是实现现代数字身份管理的第一步。   Authing 支持 OAuth2、OIDC、SAML、LDAP 等任何协议,通过调用 Authing API 或 SDK,最低五行代码快速集成单点登录的认证、授权,实现登录定制化。
Authing 官方
·
2021-07-27
·
5 人阅读
【Authing x 北森】Authing B2E 身份中台能力,助力北森开启 HR SaaS 管理新篇章
01 北森首次通过 OIDC 标准化协议与 Authing 实现应用集成 北森是一家人力资源科技公司,拥有国内领先的一体化 HR SaaS 及人才管理平台——iTalentX, 为客户提供云端 HR 软件、人才管理技术和平台的端到端整体解决方案。 此次合作,是在市场需求的推动下,Authing 作为国内大规模 B2E 场景的身份中台,集成北森 SaaS 应用,赋能其作为企业身份源,实现身份同步、组织架构同步、单点登录、全生命周期管理等能力。 此后,北森所有客户,可以轻松地将北森配置为单一企业身份源,用户只需要登录一次就可以访问所有相互信任的应用系统,实现上下游组织架构和身份数据的实时同步,从而更加高效便捷地管理内部员工及合作伙伴的账户全生命周期。 例如,当企业需要不断处理员工的进入、改变或离开等角色时,通过集成配置,向下游应用灵活地自定义提供身份同步数据,仅需一次增删改操作,即可实时地同步到下游已配置的应用平台上,极大提高办公效率并降低与之相关的人工错误等风险。 02 企业实施 SSO 是大势所趋 最近的研究表明,即便是小型企业,内部也平均使用近 10 个不同的应用程序,而大型企业则至少拥有 15 个以上的应用程序。眼下,几乎所有的企业都希望尽快实施 SSO。 1. SSO 提升登录体验 通过使用 SSO,为所有应用程序提供一个身份验证点,企业只需要求一次登录信息,从而为员工节省大量的时间和精力。 2. SSO 保障多平台访问安全 通过为员工提供单点登录,公司可以无缝地为其团队提供多平台访问,满足不同工作场所、不同客户端、或远程办公等需求,通过统一访问权限设置,提高业务安全系数。 借助 Authing 开放、标准化的能力, 将助力北森为其客户实现更加灵活、高效、可扩展的员工及人才管理解决方案。 03 Authing 全面赋能 SaaS 企业轻松实现现代身份管理 Authing 遵循开放标准、快速的部署、开发者友好,以及传统解决方案 1/10 的预算等多重优势,有效地满足了 SaaS 企业现有和未来的需求,为其节省大量的研发人力、费用和周期,避免身份模块的重复开发以及不断加重的 IT 负荷。通过组件化、可编程、可集成的设计,快速地实现定制化的身份方案,助力企业集中精力处理更为关键的业务,抓住国内 SaaS 快速发展的新机遇。 目前,全球有数千家优秀组织信赖 Authing 来实施他们员工和客户的身份管理战略。为更好的服务于客户,Authing 的应用合作网络正在迅速扩展,目前已覆盖云计算、项目管理、 ERP、办公软件等领域几乎所有的主流应用,包括 Google Workspace、 WordPress、Github、AWS、飞书、企业微信、钉钉、ZOOM、Jenkins、JFrog、Salesforce、Zabbix、Confluence、GitLab 等。 更详细信息请查阅官网 www.authing.cn。
万字长文!深度剖析身份验证的工作原理(建议收藏)
身份验证是与用户建立数字信任关系的基础部分,现代的身份管理系统可以自动帮助您执行:收集有关用户的信息,验证他们的身份是否与他们的实际身份相符,并允许他们的注册或访问请求……所有这些都是实时发生的,无需人工干预,从而创建了一种不会影响用户体验的安全身份验证功能。 身份欺诈每年都会使个人和公司损失大量资金,根据 Javelin 2020 年身份欺诈调查,2019 年身份欺诈的总成本接近 170 亿美元,现在这个数字更高。由于这些非常真实的风险,可靠地验证用户身份的能力是安全基础设施的关键组成部分。 以下为您详细剖析身份验证的工作原理,请收藏~ 01 身份验证的本质 身份验证存在的意义是什么?为了对那些有安全需求的特定资源进行访问控制,只让某些特定的主体(个人、公司、甚至是一段代码)对其执行某些特定的操作(查看、修改等)。因此,对于想要访问资源的主体,需要按照顺序达成如下两个条件: 1.认证(Authentication):知道 ta 究竟是谁2.授权(Authorization):知道 ta 有没有权限对资源执行试图执行的操作     认证  认证是决定一个主体(之后统称「用户」)究竟是谁的过程,换句话来说,是将「当前意图访问资源的用户」和「提前存储好的身份信息」对应起来的过程。显然,这个操作需要由身份信息的持有者来完成,我们称其为「IdP(Identity Provider)」,它存储的身份信息列表称为「用户目录」或「用户池」。 所谓的「身份信息」可以是任意格式,包含但不限于以下两种内容:用户的唯一标识符(可以是唯一的用户名、随机字符串、UUID 等),以及只有该用户才能提供,用来确认该用户身份的私密信息(密码、指纹等)。前者可以是公开的,但后者必须是私密的,只有 IdP 和用户自身才能持有。 为了完成认证,用户必须首先「宣称」自己是谁,并且这个宣称需要以某种形式和用户目录中的唯一一条记录产生关联。显然,最简单的办法就是直接向 IdP 宣布自己的唯一标识符。之后,用户需要通过某种保密的途径悄悄告诉 IdP 自己的私密信息,IdP 确认无误后,就可以将当前正在进行请求的用户和用户目录中的身份信息对应起来,如此一来,用户在 IdP 上的认证过程就完成了。 授权  确认了用户的身份之后,下一步就是确认用户到底有没有权限访问想要访问的资源了。拥有身份信息后,这一步就变得很简单了——只需根据对应资源的权限设置,检查用户的对应操作是否被允许即可。 02 身份和资源的分离  在最简单的身份模型中,身份持有者(IdP)和资源持有者运行在同一个上下文中。这意味着一旦 IdP 完成了某个用户的认证,资源持有者立刻就能知道(例如通过数据库查询)用户的身份信息。 之后用户访问资源时,资源持有者就能利用这一信息来决定是否允许用户的操作(相当于自己执行授权),或者把这一决定交给 IdP 来做(相当于 IdP 执行授权)。 这种模型的缺点显而易见——每个应用都要维护一套自己的用户目录,不同应用之间无法共享身份信息。为了解决这个问题,一个自然的想法就是将 IdP 独立出来,让所有资源持有者都从 IdP 处获取用户的身份。 这种做法存在一个前提条件:当一个用户在 IdP 上完成了认证之后,资源持有者必须得知这一点,并能从 IdP 处获取用户对应的身份信息,而且这一渠道必须是可信的,身份信息不能被恶意篡改。在实际应用中,资源持有者一般会在用户访问资源时,向 IdP 获取用户的认证状态和身份信息。如果成功,之后的授权步骤就和上面一致了。 独立的 IdP 有一个天然的好处——只要用户在 IdP 上进行过了认证,其下关联的所有资源持有者都能获取到用户的身份信息,正所谓「一次认证,到处访问」。所谓的「单点登录(SSO)」本质上就是如此。 由于 Web 应用天生的无状态性,资源持有者并不能确定访问资源的用户和在 IdP 上认证过的用户是同一个,因此用户每次访问资源时都需要提供身份标识符和密码,由资源持有者向 IdP 进行确认。 为了解决这一问题,IdP 在完成认证时可以向用户颁发一个临时的「令牌(Token)」,这个 Token 存储着用户目录中的用户身份,只有用户本人才能持有,并且经过 IdP 的数字签名。 用户访问资源时,通过 Cookie 等手段自动向持有者提供 Token,持有者可以在本地利用签名验证 Token 的真实性和有效性,并且从 Token 中获取到用户的身份信息,无需再经过 IdP 了。为了防止 Token 从用户处泄露,它只在短时间内有效,失效后必须由 IdP 重新颁发。 最著名的 Token 技术是「JWT(Json Web Token)」,它也是 OIDC 协议(之后会解释)的一部分。除此之外,SAML 协议中的「断言(Assertion)」也可以起到和 Token 相同的作用。 当然,用户的登录态也可以由资源提供者来维护,资源提供者在向 IdP 确认用户身份后自己向用户颁发一个类似的 Token,存放在用户 Cookie 中。此时的 Token 可以实际存储身份信息并进行签名,也可以作为一个索引的 Key,指向存放在资源提供者后端的,从 IdP 处获得的身份信息(也就是所谓的 Session)。 值得注意的是,在分离模型中,如果授权步骤由 IdP 执行,用户在 IdP 上进行授权时还需要提供自己想要访问的资源种类和执行的操作,IdP 签发 Token 时也需要将这些信息写在 Token 中,以便资源持有者核验。「资源」和「操作」的二元组被称为「Scope」,OIDC 登录时传人的其中一个参数就是它。 03 由用户决定的授权(OIDC 协议) 之前的讨论中存在一个隐含的假设——资源的所有权并不在用户手中,而是在外部的管理者手中,因此用户访问资源时才需要首先获取权限。然而在当今的互联网中,很大一部分信息都是用户产生的,用户理应拥有自己资源的完全控制权限。 在这种场景之下,「授权」的概念依旧存在,只不过被授权的主体不再是用户,而是「想要访问用户资源的第三者」,而颁发权限的主体也不再是管理员,而是用户自己。此时,这个「第三者」被称为「SP(Service Provider)」,也称为「Client」,而用户资源的存放处依然称为「资源提供者」。由于以下的讨论仅涉及授权而不涉及认证,为了方便起见,不妨假设「资源提供者」和「IdP」运行在同一上下文中,统称「IdP」,同时负责认证用户身份和提供资源。 举个例子,用户想在自己的微信中看到自己 Github 账号的状态,在这种情况下,微信是 SP ,Github 是 IdP,微信需要访问用户存储在 Github 下的资源(账号状态)。 由于微信和 Github 是两个互相不信任的应用,也因为用户有权控制其在 Github 下的资源,Github 不能在未取得用户许可的情况下,向微信提供任何用户资源。因此,微信首先需要指引用户前往 Github 进行认证和授权,这通常是用重定向用户浏览器来实现。 Github 会首先进行认证操作,确认用户的身份(显然只有用户本人才有权向第三者提供他的资源的访问权限)。身份验证通过后,Github 还会根据管理员配置的权限列表,确认用户本身拥有微信所请求资源的对应访问权限(因为请求的资源也可能不完全属于用户)。这一点也确认无误后,Github 就会弹出授权确认页面,向用户确认「是否授予微信对应权限」。用户确认完成后,Github 就会签发一个 Token,由用户转交给微信,微信方只需向 Github 提供这个 Token 就可以访问之前请求的资源了。 作为标准身份协议之一的 OIDC 正是为此种场景而生。OIDC 的认证和授权分为四种模式:授权码模式(Code)、隐式模式(Implicit)、密码模式(Password)、客户端证书模式(Client Credential)。 授权码模式  授权码模式是最为规范的模式。它的主要步骤如下: 1.SP 将客户端重定向到 IdP 的 OIDC 授权地址,附上自己请求的权限(Scope)和一个回调地址2.IdP 在自己的页面上完成认证,并由用户确认权限3.IdP 通过客户端向 SP 的回调地址发送一个授权码(Code)4.SP 的后端向 IdP 的另一个接口发出含有 Code 的请求,得到 IdP 颁发的 Token 授权码模式的优点在于 Token 不由用户,而是由 SP 持有,降低了意外泄露带来的风险。值得注意的是,用户在 IdP 上进行认证和授权的过程是 IdP 自行规定的,和 OIDC 协议无关。在 OIDC 协议中,IdP 颁发的 Token 是 JWT。 隐式模式  隐式模式可以看作省略了 Code 的授权码模式。它的主要步骤如下: 1.SP 将客户端重定向到 IdP 的 OIDC 授权地址,附上自己请求的权限(Scope)和一个回调地址2.IdP 在自己的页面上完成认证,并由用户确认权限3.IdP 通过客户端向 SP 的回调地址直接发送 Token 可以看到,此时的 Token 经过了用户的客户端,容易被中间人窃取。由于访问用户资源的是 SP 而不是用户本人,只让 SP 持有 Token 永远是更为正确的选择。 密码模式  密码模式在隐式模式的基础上进一步省略了 IdP 上的授权过程。它的主要步骤如下: 1.SP 在自己的页面上请求用户输入在 IdP 上的用户名和密码2.SP 向 IdP 的 OIDC 授权地址发起请求,附上用户输入的帐密3.IdP 确认帐密的正确性,然后在响应中直接发送 Token 密码模式只应用在 IdP 和 SP 互相信任,或者 SP 由用户本人控制(例如移动端或桌面应用)的情况下,因为用户的帐密经过了 SP,只要 SP 愿意,完全可以通过用户的帐密在 IdP 上无限制访问用户的全部资源。也正因如此,密码模式中让用户确认权限是没有意义的,SP 获取的一定是用户资源的完全访问权限。 客户端证书模式  客户端证书模式和用户无关,只用于在 IdP 上授权特定 SP 访问特定资源。它的主要步骤如下: 1.SP 提前在 IdP 上注册一个证书(一般是账号 + 密码)2.SP 向 IdP 的 OIDC 授权地址发起请求,附上自己的证书3.IdP 确认证书的正确性,然后在响应中直接发送 Token 显然,客户端证书模式也只应用于 IdP 和 SP 互相信任,或是 SP 只访问用户无关资源的情况下。由于没有征得用户的同意,如非必要,IdP 不应授权 SP 访问用户的私密信息。 04 标准身份协议除了 OIDC 协议之外,还存在着许多标准身份协议,例如 SAML 和 CAS。它们的存在意义都是类似的:为了能让素不相识的 SP 和 IdP 进行快速对接,在用户的许可下让 SP 在 IdP 处完成授权,从而访问 IdP 下资源提供者的资源。 SAML 协议和 OIDC 的隐式模式类似。发起 SAML 请求的 SP 会将客户端重定向到 IdP 的 SAML 端点,附上一段 base64 编码的 xml 格式信息,包含 SP 自身信息和本次操作的信息。IdP 验证 xml 后,同样会在自己页面进行认证和用户授权,随后向 xml 中包含的回调地址发送另一段经过签名的 xml,包含用户的身份信息。 这段 xml 称为「SAML 断言」。SP 接收到断言后,就可以利用断言去资源提供者处请求数据了。 CAS 协议类似 OIDC 的授权码模式,它的授权码称为「Ticket」。它和 OIDC 唯一的不同点在于 SP 用 TIcket 换到的是一段 xml 格式的身份信息,并且没有经过签名,因此 CAS IdP 和资源提供者必须通过其他可信渠道进行用户认证信息的传递(当然也可以运行在同一上下文),不能仅通过 SP 提供的用户身份信息来信任 SP。 事实上,如果实际需求只是让用户在 IdP 处进行验证和授权,并访问本 IdP 下资源提供者的资源,而不涉及第三方应用,也可以使用标准协议。此时用户和 SP 是同一概念,Token 由用户自身持有。但是不难发现,这种情况下,标准协议不仅没有任何优势,反而增加了适配协议的复杂性——原本事情只要 IdP 提供一个登录页面,给用户一个 Token 就解决了。如果一定要使用标准协议,应当选择尽可能靠近原始登录流程的协议,例如 OIDC 的密码模式。 05 联邦认证 我们假设所有的认证过程都只利用 IdP 自身存储的身份信息来完成。事实上,IdP 还可以把认证过程委托给其它的 IdP,此时委托方 IdP 对于被委托 IdP 而言相当于一个 SP,从被委托 IdP 处获取认证成功后返回的身份信息,然后重新扮演 IdP 的角色,利用该信息完成用户在自身上的认证。 当然,委托方 IdP 还可以把身份信息复制到自己的用户目录内,创建一个新账户,之后的认证就无需经过第三方 IdP 了。这种场景就是「联邦认证」。既然联邦认证本质上也是 IdP 和 SP 之间的交互,那么使用标准身份协议无疑是最快捷的方式。 举个例子,微信中「使用 Github 登录」的按钮就是一个联邦认证的实例。 当用户点击这个按钮后,微信会作为 SP,利用标准身份协议向作为 IdP 的 Github 发起认证和授权请求,回调地址则是微信内部的地址。 用户在 Github 的页面上进行认证,并授权微信访问自己的用户信息(用户信息也是资源的一种,所以 IdP 本身就是一个资源提供者)后,Github 就会向微信发送 Token。 随后微信用 Token 向 Github 请求用户身份信息,在自己的用户目录中查找是否存在匹配的身份信息(一般都是利用某种在外部 IdP 中唯一且固定不变的标识符作为 Key,例如 openid),找到则将其关联上当前用户,找不到则新建一个条目。 不论哪种情况,微信最终都能得到用户在自身用户目录中的身份信息,换句话说就是完成了认证。 在联邦认证中,一个重要的问题是如何将位于两个不同身份源,但表示同一用户的信息进行匹配。可以用在两个 IdP 中相对唯一的信息,例如手机号或邮箱进行匹配。这一匹配过程不能覆盖委托方 IdP 中原有的身份信息,否则就会出现以下安全问题:假设外部(被委托) IdP 中的身份信息会覆盖内部(委托方) IdP 中相同邮箱的信息,那么一旦有人故意在外部 IdP 中注册一个内部 IdP 中已有的邮箱,他就可以直接利用联邦认证去登录内部 IdP 中同一邮箱的账户,哪怕这个账户原本不属于他。 理论上来说,在从外部 IdP 导入身份信息(也就是用户第一次通过该身份源登录)时,将其与任意一条已有的内部身份信息对应都是不安全的。这些身份信息应当永远关联一个新创建的内部账户,然后,如果该用户的身份信息能匹配到内部 IdP 中已存在的一个账户,首先确认他确实拥有这个账户,然后才能建立新的关联。 无论哪种情况,已经建立的关联都不应被修改,哪怕用户在外部身份源修改了身份信息,他在内部 IdP 对应的身份信息 ID 也不应改变。 在关联建立之后,用户再通过该身份源登录时,就可以直接利用这个关联查到用户在内部 IdP 中的身份信息了。
Authing 云端单点登录技术,助力 SaaS 企业轻松上阵加速业务布局 | 案例
中国 SaaS 行业一直受到国内腰部企业的数量规模以及支付意愿的影响,和西方相比还是相对扩张缓慢。但在疫情影响下,加速催生了数字化的各种需求和支付意愿, SaaS 行业正迎来新一轮的发展机遇。 无可否认,软件即服务是大势所趋,所有的 SaaS 企业都希望能聚焦核心业务,降低其他重复性的开发和 IT 负荷。 所以,通过低成本快速集成灵活可扩展的应用成为了公认优选。 1 什么是单点登录技术 随着应用不断增加,几乎所有企业都深受重复开发身份模块、统一用户管理的苦恼。 SSO(单点登录)作为整体的单一登录点,用户只需登录一次,就可以访问其他所有相互信任的应用系统。 想象您的家里,它有大门及各种相连但独立上锁的房间。如果使用类似 SSO 的系统,管理人员将改为授权信任的访问者,仅使用一把钥匙打开大门,免去再使用单独的钥匙进入各个房间的重复性动作。 这就是 SSO 系统的总体思路。比如您现在可以通过北京市统一身份认证这一个账户,无缝登录北京市政务服务各种单独的应用程序。 2 实施单点登录的挑战 通常,企业尝试自己设计 SSO 解决方案时,都会遇到常见的开发难题,以及高昂的成本问题。 一方面,跨不同类型的目录集成身份是一项挑战。比如打通不同应用程序的用户数据,比如兼容不同设备和操作系统等,都颇具有挑战性。 然后是用户迁移的问题。不同应用,不同分支机构,可能档案信息都不同,将所有数据迁移到一个单一的真实来源,并实时自动化地操作更改删除等权限设置,这都是一个非常让人头疼的问题。 但是使用第三方的 IDaaS 平台,可以便利地处理种种身份问题,无需从头写代码去构建,无需重复开发模块,快速简单地集成各种所需的应用,并且定制灵活可扩展的解决方案。 3 SaaS 企业优选案例 木瓜移动:专注于 SaaS 和出海营销服务,触达全球超 20 亿的用户终端。 问题场景: 内部应用十余个,身份分散账密多,员工访问不同系统时,需多次登录认证,体验不佳且影响办公效率。需要将目前使用的飞书作为企业统一身份源,与其他应用实现用户和组织架构的同步,实现单点登录。 解决方案: 第三方身份源配置:Authing 身份云已预集成了飞书应用,快速实现将飞书作为身份供应体系,打通木瓜移动内部组织架构,并实现木瓜移动现有的 Jira、Getlab、Confluence、Kibana及自研 CRM 等十多个内外部应用的身份源打通。实现一个账号密码登录所有应用,解决内部员工登录问题。 在 Authing 中,企业身份源包含两类:办公应用(如飞书、企业微信、钉钉)与标准协议应用(如支持 OIDC、SAML、CAS 等标准协议的身份源),可以通过配置企业身份源连接,实现使用第三方身份源登录 Authing 应用,从第三方身份源导入组织机构和用户目录。 集成基于角色的访问控制:通过用户、角色、资源、授权的组合,在控制台轻松直观地实现灵活、细粒度的权限模型。 单点登录技术仅是身份解决方案的一部分,全方位的身份及访问管理解决方案,还包括账号同步、多因素认证、自动化权限管理等功能。
Authing 社区好文推荐:如何 15 分钟开发一个很棒的登录系统
据 Stripe 的一项全球研究,开发人员每周近 75% 的时间花在维护任务上。低代码开发有助于解决组织数字化转型的许多常见挑战:比如提高开发的敏捷性,更快地推出项目抓住商机,更轻松地替换或升级旧系统的关键组件,极高的扩展性等。 到 2025 年将有 60% 的 CIO 使用低代码工具,超过 65% 的应用程序开发将在低代码环境中进行。 Authing 的低代码方式,可以帮助开发者在几分钟内实施身份认证。 如果您正希望解决身份管理的问题,Authing 已经被验证提供了一个很棒的方法。以下三种方式,帮助您实现出色的登录认证: No Code  使用 Authing 托管登录页,无需一行代码,您可以在几分钟内将为您的用户定制登录体验,配置注册页面,自定义配置手机/密码/扫码以及多种社会化登录方式、自定义密码强度配置、主题色配置、注册信息配置、多因素身份验证等……                                                 示例:在应用配置中修改登录注册方式                                                       示例:在自定义密码强度中配置密码强度   Low Code  使用 Authing 提供的内嵌登录组件,可以集成到您的 Web 和移动端项目中,可以支持完整的 UI 自定义功能,所有资源打包起来只有几百 kb。 内嵌登录组件由 Authing 构建和更新,使用行业最佳实践安全性设计,几行 JavaScript 代码就可以集成到您开发的项目中。它可以直接从 CDN 或 NPM 加载,也可以从源代码构建。Authing 登录组件同时提供 Javascript 原生、React、Vue 和 Angular 等多种集成模式。 您无需设置完整的开发环境,无需从头开始编写代码,通过运行在云端的 JavaScript 代码,可以让您扩展、自定义 Authing 能力;还有大量丰富的函数模板,帮助您快速上手;自定义数据库,使用自己的数据库保存用户数据;自定义处理用户注册、登录等行为监测……                                                   示例:Authing Guard 自动从服务器拉取配置                                                   示例:自动开启多因素认证  Pro Code  您可以随需调用 Authing 提供的 1000+ API 以及十余种语言和框架的 SDK 资源,基于此灵活地组合出适合的认证流程和自定义 UI 页面,快速集成预设的各种主流应用系统,为您的内部/外部用户实现统一身份管理,创造安全无缝的登录体验…… Authing 为前端开发者提供轻量级、开发者友好的 Auth SDK(支持 JavaScript/Node、Java、Python、PHP、C# 等语言),能够让您更灵活、快捷、安全地实现认证逻辑。 Authing 提供的托管登录页、嵌入登录组件、Auth SDK 底层能力都是通过 Authentication API 提供的。Authing Authentication API 支持两种调用方式:RESTful 和 GraphQL(端点为 https://core.authing.cn/graphql/v2),您也可以直接调用 Authentication API 实现认证逻辑。 以五分钟入微信网页授权登录为例 体验入口:https://www.authing.cn/developer/ 1. 开发准备在微信公众平台后台 开发 -> 基本配置 获取开发者 ID (AppID) 和开发者密码(AppSecret)。在微信公众平台后台 设置 -> 公众号设置 -> 功能设置 设置网页授权域名。域名填写:core.authing.cn。出于安全验证考虑,微信服务器需要和 Authing 服务器做一次请求验证,开发者需要下载 txt 文件,并记录文件名和文本内容。最后,在 Authing 控制台 连接身份源 -> 社会化登录 开启微信网页授权登录,并填写配置信息。                                                                示例:配置信息表单 2. 安装 使用 CDN 引入 authing-wxmp-sdk <script src="https://cdn.jsdelivr.net/npm/@authing/wxmp/dist/authing-wxmp-sdk.min.js"></script> 使用 npm / yarn npm install --save @authing/wxmp 或者 yarn add @authing/wxmp 然后通过以下方式引入 import AuthingWxmp from "@authing/wxmp"; 3. 发起微信授权 先从 Authing 控制台中获取用户池 ID const authingWx = new AuthingWxmp({ userPoolId: 'YOUR_USERPOOLID', }) 调用 getAuthorizationUrl 方法获取微信授权登录链接,修改 window.location 跳转到微信登录授权页面 // 跳转到微信授权页面 window.location = authingWx.getAuthorizationUrl()  4. 获取用户信息 // 若在回调页面 authingWx 未初始化,需要先初始化,具体初始化方式参考上文 const { ok, userinfo, message } = authingWx.getUserInfo() if (ok) { // do with userinfo console.log(userinfo) } else if (message) { // message 中包含了错误提示 alert(message) }  5. 使用 token 维持登录状态 const axios = require("axios"); axios .get({ url: "https://yourdomain.com/api/v1/your/resources", headers: { Authorization: "Bearer ID_TOKEN", }, }) .then((res) => { // custom codes }); 识别用户身份之后,可能还需要对该用户进行权限管理,以判断用户是否对此 API 具备操作权限。 6. 总结授权流程 · 开发者引导用户跳转到 Authing 设置的授权链接: https://oauth.authing.cn/oauth/wechatmp/url:userPoolId。 · Authing 和微信根据 OAuth 协议完成用户信息交互。 · Authing 将用户信息(包含 token)发送到开发者自定义的业务回调链接。 · 开发者使用 token 维持登录状态,检验 token 的合法性以及登录状态。 · 终端用户后续的请求将 token 携带上。 · 开发者在后端调用 Authing 提供的方法检验 token 的合法性以及登录状态。 · 根据 Authing 返回的登录状态和开发者自己的业务逻辑,对请求进行相应处理。
【海外】报道转载:Authing 是中国的 Okta,中国 SaaS 行业快速发展
来源:PINGWEST 英文站记者:Rebbeca Ren Although the Covid-19 pandemic has disrupted "normality" in a devastating way, digital transformation has been accelerated. Software as a service (SaaS) companies are benefiting from the trend. The stock prices of SaaS giants including Salesforce, Okta, and Twilio have almost doubled since the outbreak of the pandemic. 尽管新冠疫情以毁灭性的方式破坏了“常态”,却加速催化了数字化转型。软件即服务 ( SaaS ) 的公司正从这一趋势中受益,自疫情爆发以来,包括 Salesforce、Okta 和 Twilio 在内的 SaaS 巨头股价几乎翻了一番。In China, the sector, fueled by capital, is also expanding rapidly. According to data released by startups database IT Juzi, in the first half of 2020, 280 financing events occurred in the SaaS industry, raising a total of 35.413 billion yuan ($5.47 billion). 中国 SaaS 行业在资本的推动下正迅速扩张,据 IT 桔子统计,2020年上半年 SaaS 行业发生融资事件 280  起,总融资金额达 354.13 亿元( 54.7 亿美元)。 With the increase in the number of mobile devices and data access points in the cloud, cloud security is now the fastest-growing sector. As an important part of cloud security, identity as a service (IDaaS) is also riding on the high-speed train. Log-in–tech startup Authing has secured a $5 million exclusive investment from GGV capital in January.  随着云上设备和数据访问点的数量不断增加,云安全现在是增长最快的领域。作为云安全的重要组成部分,身份即服务(IDaaS)也乘上了高速列车。一家做登录技术的初创公司 Authing 在今年 1 月份获得了纪源资本 500 万美元的投资。 In China, the sector, fueled by capital, is also expanding rapidly. According to data released by startups database IT Juzi, in the first half of 2020, 280 financing events occurred in the SaaS industry, raising a total of 35.413 billion yuan ($5.47 billion). 中国 SaaS 行业在资本的推动下正迅速扩张,据 IT 桔子统计,2020年上半年 SaaS 行业发生融资事件 280  起,总融资金额达 354.13 亿元( 54.7 亿美元)。 With the increase in the number of mobile devices and data access points in the cloud, cloud security is now the fastest-growing sector. As an important part of cloud security, identity as a service (IDaaS) is also riding on the high-speed train. Log-in–tech startup Authing has secured a $5 million exclusive investment from GGV capital in January.  随着云上设备和数据访问点的数量不断增加,云安全现在是增长最快的领域。作为云安全的重要组成部分,身份即服务(IDaaS)也乘上了高速列车。一家做登录技术的初创公司 Authing 在今年 1 月份获得了纪源资本 500 万美元的投资。   该公司由三位 95 后合伙人创立,为企业提供基于云的身份服务比如单点登录等,集成包括阿里云,腾讯云,百度云等应用。 In March, Auth0, the American peer of Authing, was acquired by Okta for $6.5 billion, consolidating the latter's position in the IDaaS field. Okta concentrates more on pre-built, pre-configured solutions3月,Authing 的美国同行 Auth0 被 Okta 以 65 亿美元收购,巩固了其在 IDaaS 领域的地位。Okta 提供低代码方法,专注于预构建、预配置的解决方案。 The costly acquisition has brought IDaaS, which plays a central role in enterprise identity management by removing ID silos and enabling one account-access-all function, into the spotlight. According to Fortune Business Insights, the global identity and access management market is projected to reach $24.76 billion by the end of 2026, exhibiting a CAGR of 13.2% from 2018 to 2026. 高昂的收购使 IDaaS 成为人们关注的焦点,IDaaS 在企业身份管理中发挥核心作用,包括消除数据孤岛,实现一个帐户访问所有应用等功能。根据 Fortune Business Insights 分析,到 2026 年底,全球身份和访问管理市场预计将达到 247.6 亿美元,同比 2018 年增长率为 13.2%。 Authing identifies itself as an API (application programming interface)-first, developer-friendly solution for identity management. ( API allows easier embedding of content from any site or application)  Authing 提供 API 化服务、开发者友好的身份管理解决方案。( API 允许更轻松地嵌入来自任何站点或应用程序的内容)  "I have coded for more than 10 years. I noticed that people need to re-develop login and registration modules every time they develop applications, which will slow down the development progress to a certain extent. So I decided to turn identity authentication services into API forms and provide them to others," Xie Yang, the CEO, told PingWest. “我已写了 10 多年代码,深受身份模块的折磨,每做一个应用都需要重复开发登录注册、社交登录、权限控制等模块,我意识到身份会拖慢业务的迭代速度,所以我决定将身份模块抽离出来,作为独立的API 服务并提供给所有人。” Authing CEO 谢扬告诉 PingWest。 "Modularization of software development and microservices are the future. As a developer-friendly identity infrastructure, Authing will contribute to the prosperity of cloud computing in China," said the CEO.   “软件的模块化开发和微服务化是大势所趋,Authing 作为一个开发者友好的身份基础设施将为加速中国云计算的繁荣做出贡献。” Authing CEO 谢扬说。 Speaking of the investment in Authing, Wu Chenyao, executive director of GGV Capital, said they felt the trend of SaaS services going to API-ization and SDK (software development kit)-ization from its global investments. 谈及对 Authing 的投资,纪源资本执行董事吴陈尧表示,他们从全球投资中感受到了 SaaS 服务向 API 化和 SDK(软件开发工具包)化的趋势。 "In China, we clearly see the rapid development of enterprise digital transformation and IT infrastructure innovation, said the venture capitalist. "With just a few lines of code, non-core business function modules can be integrated into your own service, which enables you to focus on your core business.” “在中国,我们清楚地看到了企业数字化转型和 IT 基础设施创新的快速发展,”风险投资人说,“只需几行代码,非核心业务功能模块就可以集成到你自己的服务中,让你更专注于自己的核心业务。” SaaS reduces the enterprise's demand for IT talents while providing the latest technology applications to meet theirs requirements for digital management. Wang Huiwen, the co-founder of on-demand delivery giant Meituan, believed that the lack of well-capitalized mid-sized companies is the reason why enterprise-oriented SaaS has been developing relatively slowly in China.  SaaS 降低了企业对 IT 人才的需求,同时提供最新的技术应用,满足企业对数字化管理的需求,美团的联合创始人王慧文认为,缺乏中型腰部企业是中国的 SaaS 发展相对缓慢的原因。 Traditionally, mid-sized firms are the landing point for SaaS companies in both the US and Europe, but in China, comparatively inexpensive labor and low willingness to pay for software hold back the expansion of SaaS.  中型企业一直以来是美国和欧洲 SaaS 公司的着陆点,但在中国,相对便宜的劳动力和低软件支付意愿阻碍了 SaaS 的扩张。 Therefore, the current valuation of Authing is much lower than its western matches. In March, Vancouver-based startup Trulioo has raised $394 million at a $1.75 billion valuation for its identification technology service. 因此,Authing 目前的估值远低于其他西方公司。今年 3 月,总部位于温哥华的初创公司 Trulioo 以 17.5 亿美元的估值为其身份识别技术服务融到了 3.94 亿美元。 Now the informatization level of mid-sized enterprises remains fairly low in China, where Tencent's instant messaging app and e-mail service dominate the office. 中国中型企业的信息化水平仍然较低,中美差距还是相当明显的。在中国,腾讯的即时通讯应用和电子邮件服务在办公领域占据主导地位。 Besides Tencent, giants such as Alibaba, Baidu, and Bytedance are all cultivating and promoting their own cloud-based services, which also poses a threat to start-ups.  除了腾讯,阿里巴巴、百度、字节跳动等巨头都在培育和推广自己的云服务,这也对初创企业构成了威胁。  But Authing believes that neutrality is their advantage. "Tech barriers exist between the giants so they are unable to integrate with each other, but we can blend all of them into Authing," said the CEO. 但 Authing 认为中立是他们的优势,“巨头之间存在数据壁垒,它们无法相互整合,但我们可以将它们全部集成到 Authing 的应用中。”Authing CEO 谢扬说。 According to the company, it currently serves hundreds of corporate customers, mainly state-owned enterprises and financial institutions, and tens of millions of users and corporate employees are using its secure access function. 该公司目前服务于数百家企业客户,包括央国企公司和金融机构等,支撑数千万用户和企业员工的安全访问体验。 The Beijing-based company also provides services for French advertising firm JCDecaux and Italian bank UniCredit. 这家总部位于北京的公司还为法国广告公司德高 JCDecaux 和意大利银行 UniCredit 提供服务。 Xie told PingWest that the company started with only 2 people and is expected to grow into a team of 100 people by the end of this year. Among them, staff of product and R&D will account for 68%. Authing CEO 谢扬告诉 PingWest,公司从 2 个人开始创业,预计到今年年底将成长为 100 人左右的团队,其中 68% 为产品和研发人员。 Cloud infrastructure spending in China increased from about $107 billion in 2019 to $142 billion in 2020, surging more than 32% in the last quarter of the year. Industry analysis provider Qianzhan forecasts that the size of the country's enterprise-oriented SaaS market will reach 74 billion yuan ($11.43 billion) in 2021, and will exceed 270 billion yuan ($41.71 billion) by 2026. 中国的云基础设施支出 从 2019 年的约 1070 亿美元增加到 2020 年的1420 亿美元,2020 年最后一个季度飙升超过 32%。据前瞻产业研究院预测, 到 2021 年中国 SaaS 市场规模将达到 740 亿元(114.3 亿美元),到 2026 年将超过 2700 亿元(417.1 亿美元)。 Some investors believe software is the future and finds it valuable to review trends underway in the US. “In the next 20 years China will follow the US in using software to improve enterprise efficiency,” said Patrick Zhong, founder of M31 Capital. “We’re not saying it will be the exact same path as the US, but it’s a reference point.” 一些投资者认为软件是未来,从美国正在经历的趋势来看很有价值。“未来 20 年,中国将和美国一样使用软件来提高企业效率,这并不是说它将与美国完全相同,但它是一个参考点。” M31 资本创始人仲雷表示。 New opportunities are triggering the development of the SaaS sector in the country—the demographic dividend is waning, Covid-19 has accelerated the adoption of cloud and remote work, and the government has been vigorously promoting cloud adoption. It is foreseeable that startups like Authing will keep coming out to enrich the entire ecosystem. 新的机遇正在引发中国 SaaS 行业的繁荣发展——在新冠疫情的催化加速下,不仅是企业甚至包括政府部门,都在大力扩展云服务以及远程办公模式。可以预见,像 Authing 这样的初创公司将不断涌现,丰富整个生态系统。
Authing 合作网络上架应用介绍(一)
Authing 已经构建了一个合作网络,可以帮助企业管理员和开发者更简单、高效的完成应用单点登录。任何用户想要的应用都会直接出现在 Authing 的合作网络中,并以最简单的方式去使用。本期向各位读者介绍 6 个上架应用:Zoom、Google Workspace、Github Enterprise、Wordpress、飞书、Jira。ZoomZoom 是现代企业视频通讯领域的领导者,为跨移动设备、台式机和会议室系统的视频/音频会议、协作、聊天和网络研讨会提供简单可靠的平台。查看/获取应用:https://www.authing.cn/apn/detail/zoom Google WorkspaceGoogle Workspace(原 G Suite):企业协作工具,一整套采用了 Google 人工智能技术且安全可靠的云端协作及高效办公应用,包括 Gmail、文档、云端硬盘、日历、Meet 等。查看/获取应用:https://www.authing.cn/apn/detail/google-workspace Github EnterpriseGithub Enterprise 是针对 Enterprise Cloud 和 Enterprise Server 的统一产品,允许组织自行配置基于云端或者自建的 GitHub。查看/获取应用:https://www.authing.cn/apn/detail/github Wordpress全球最热门的网站构建器。42% 的网页在 WordPress 上构建。越来越多的博主、小型企业和《财富》500 强公司使用 WordPress,其数量超过了其他所有选项的总和。查看/获取应用:https://www.authing.cn/apn/detail/wordpress 飞书飞书是真正的一站式企业沟通与协作平台,整合即时沟通、日历、视频会议、电话会议、云文档、云盘、工作台、考勤打卡等功能于一体,打造高效的办公方式,加速企业成长。查看/获取应用:https://www.authing.cn/apn/detail/lark Jira在 Jira 中可以计划、跟踪和管理您的敏捷软件开发项目。自定义您的工作流、进行协作以及发布出色的软件。Jira在 Jira 中可以计划、跟踪和管理您的敏捷软件开发项目。自定义您的工作流、进行协作以及发布出色的软件。查看/获取应用:https://www.authing.cn/apn/detail/jira查看/获取应用:https://www.authing.cn/apn/detail/jira