身份很容易。毕竟，每个人都有一个。认证？可能就更不复杂了。任何使用智能手机的人每天都要认证几十次才能使用它，这甚至还没有涉及银行、工作或社交媒体所需的远程服务。也许正是这种明显的简单性吸引了我在大约五六年前进入身份系统的世界。
在这之前的几年里，我主要从事产品或服务的开发工作，在那里，我们开发人员的一个共同主题是被告知需要做什么的一些模糊描述，然后花上几天或几周的时间尽力去做这件事。只有当我们完成时，我们才会发现我们所做的并不是真正的要求，我们需要花大量的时间来重构我们所建立的东西，以支持这些改变或额外的要求。在冲刺结束时，我们会有礼貌地抱怨，如果我们幸运的话，事情会改善一段时间，然后在几周后恢复原状。
不过你可以放松一下，这篇博客并不是要讨论敏捷、Scrum或其他一些方法论如何解决这个挑战。相反，这篇文章的重点是我们如何以开放政策代理（OPA）的形式达成一个开源的解决方案，满足我们以代码形式处理政策的所有目标。但首先，一些背景。
有一天，我的团队被赋予了新的职责。我们已经工作了一段时间的现代API将被移交给一个新的团队，而我们被分配了一个非同小可的任务，即建立一个急需的新身份平台--它将取代目前正在尝试这样做的少数几个传统平台。一些要求包括有一个单一的用户ID概念和一个平台来处理跨越几十个不同的产品和系统的单点登录（SSO）认证。
这对我们来说意味着所有的变化，其中一个更有趣的变化是引入了标准工作。我们可能都在某种程度上与他们合作过，但直到那一刻，我们才真正与他们紧密合作。以前我们处理的是模糊的要求和松散的规格，现在我们面对的是所有这些文件，它们会准确地说明什么是对的，什么是错的。矛盾的是，这一切的严格性是一种解放。
在几个月的时间里，我们都沉浸在规范和标准文件中，学习如何使用OAuth2获取访问令牌，OpenID Connect 如何为我们的应用提供急需的身份层，以及SCIM如何在不同的身份后端存储中简化和标准化身份。从我们所学到的知识中，我们能够建立一个身份系统，在未来的许多年里为公司服务。
第一次发布的日子最终到来了，奇迹般地，一切似乎都在运转。人们将通过前端登录，身份系统将在后端发出令牌，然后
