躲不开创建身份验证?开发者福音,更安全、更低成本的方案( 二 )


设计这些系统时非常容易犯错误 , 有很多细节需要牢记:超大型的公司的数据库中没有散列密码(或者没有正确散列密码) , 不慎在日志文件中以明文方式转储密码 , 并且重置表单 , 很容易将其暴露 , 被社会工程等利用 。

躲不开创建身份验证?开发者福音,更安全、更低成本的方案
本文插图

图源:unsplash
众所周知 , 正确管理密码并不容易 。 但管理用户名也很难吗?例如 , 看起来相同的两个用户名并不意味着两者是一样的 。 詹姆斯·班尼特在2018年的演讲《嗨!我的名字是……》中介绍了在用户名这样“简单”的东西上可能会出现什么问题 。
最后 , 应用程序可以从许多提供商已经提供的高级安全功能中受益 , 其中包括对多重认证和安全令牌的支持 。
这些服务的验证服务并不总是免费的 , 尤其是在应用程序库规模增大的情况下
还有什么不是免费的吗?遭到黑客攻击 , 必须支付损害赔偿 , 其中包括直接补救费用(如果有的话) , 紧急修复应用程序所花费的时间 , 特别是失去用户的信任 。
甚至在此之前 , 完成一个安全的身份验证系统并对其进行维护、操作用户数据库等 , 都是以时间和资源为代价的 。
笔者是非常资深的开发人员 , 知道如何建立一个安全的认证系统
在明白了安全构建这些东西并非想象的那么简单之后 , 如果你是个资深开发者 , 最好把时间花费在应用程序的其他部分 , 为用户提供更多价值 。 例如 , 如果真的想在认证系统方面任职 , 那么可以考虑加入Microsoft , Auth0 , Facebook等公司 , 致力于改进他们的身份平台 。

躲不开创建身份验证?开发者福音,更安全、更低成本的方案
本文插图

图源:unsplash
应该保持对用户的控制
首先 , 为什么?除非你在创建一个新的Facebook , 那么数据的确是最大的财富 , 并且收集的越多越好 , 但通常这并不是刚需 。
此外 , 收集更多关于用户的数据甚至可能会增加遵守GDPR等法规的成本 。 这将使违规行为潜在的危害性更大、代价更高 。
上述大多数解决方案仍然有助于深入了解客户及其行为 。
托管服务往往有些棘手 , 因此如果担心服务迁移的能力 , 可以考虑采用自托管的身份认证服务器 。 但请记住:这些系统的维护更加复杂 , 并且由于数目过大 , 往往缺乏先进的安全功能 。
躲不开创建身份验证?开发者福音,更安全、更低成本的方案
本文插图

如何开始
好消息是 , 上述提供商(Auth0, Azure AD, Google Identity Platform, Okta)和更多的提供商都使用相同的协议:OpenID Connect 或 OAuth 2.0 。 两者都是现代化的行业标准协议 , 有着针对每种编程语言和框架的客户端库 。
具体的步骤包括:
1. 向网络身份提供商注册应用 。 提供商会提供一个应用程序ID(或客户端ID)和一个密钥(或Client Secret) 。
2. 定义应用程序所需的权限 。 除了返回用户的配置文件外 , 根据身份服务 , 还可以访问更多的数据 , 包括用户的电子邮箱 , 云存储等(例如通过Office 365或G Suite) 。
3. 在应用程序中包含客户端库
笔者不会详细解释OpenID Connect是如何工作的 , 但是总体的流程包括应用程序将用户重定向到身份提供程序服务器上的页面 。 用户将在那里完成身份验证流程 , 然后和JWT令牌一起重定向到应用程序 。

躲不开创建身份验证?开发者福音,更安全、更低成本的方案
本文插图

图源:unsplash
这种JWT令牌是加密签名的 , 其有效期受限 , 可用于为用户维护会话 。 换句话说 , 只要令牌有效 , 当应用程序识别到令牌的时候 , 就可以将请求视为来自于令牌所属的用户 。


推荐阅读