OAuth 和审核日志

Question

在我的公司，我们有自己的身份服务器 4 实现，我们用它来颁发访问令牌并授予对 API 的访问权限。我面临的问题是，我们目前在每个数据库实体上都有审计字段，其形式为

CreatedByUserId BIGINT NOT NULL
CreatedDateTime DATETIME NOT NULL
UpdatedByUserId BIGINT NOT NULL
UpdatedDateTime DATETIME NOT NULL

直到最近这一切都还好。我们有一些数据库中间件，可以从访问令牌中读取子声明并使用它来填充审核字段。但我们现在需要运行一个自动化作业，每 30 分钟更新一次数据库。问题是，这现在提出了一个问题，如果我通过客户端凭据流处理或接收 api 调用，而交互中没有用户，我应该如何记录更新该实体的“Service X”或插入该记录的“OtherCompany.ApiClient”。我能做些什么？如何审核用户和非用户？即使它需要架构更改，我也需要想法。

这些审计字段的主要用例是，我们的应用程序中有某些页面，业务要求我们显示哪个用户上次更新实体以及何时更新。显然，这些审计字段并不是我们真正的事实来源，因为当数据发生变化时，我们会在幕后进行实际的每个属性审计日志记录。

我的一个想法是将 CreatedByUsername 和 UpdatedByUsername 字段添加到表中，然后使用访问令牌中的信息（在客户端凭据令牌的情况下是用户的用户名或客户端的显示名称）来填充这些值。这样我们就可以在行级别获得所需的所有显示信息。这种方法的唯一问题是我们的很多护士都是女性，而女性结婚后往往会改变自己的名字。因此，要么他们必须根据两个姓氏搜索实体，要么我们必须在他们更改名称时传播用户名更新事件，以追溯更改每个其他服务中的名称。

有什么想法吗？

Answer 1

用户 ID 不应该是名称。我总是尝试在不透明的访问令牌中使用主题声明，例如 UUID。因此，名称更改不会产生影响，但名称更改确实会产生影响。

在您的

domain specific data

中可能有不同的历史用户 ID，例如数据库主键，代表护士，映射到代表患者护理的资源。如果是这样，这可能是在审核记录中使用更好的用户 ID。

还请记住，用户名等个人数据如今通常受到 GDPR 等法规的约束。一个好的做法是仅将此类字段存储在授权服务器中，并仅将它们临时返回到 OAuth 令牌中的应用程序级组件。我会避免非规范化的名称字段。

应用程序需要显示的是供人类使用的报告。这与最佳存储格式不同。我会通过某种连接来管理它，无论是在代码中还是在数据库中。

后端作业并不是真正的用户。一种选择可能是将此类更新的审核用户保留为空，然后对其进行特殊解释。另一种可能简化报告实现的选项可能是为后端作业创建某种伪用户记录。

Answer 2

基于 @Gary 而不是使用用户名，生成并分配 UUID 作为用户的唯一标识符。这可以被认为是主要的，以避免与名称更改相关的问题。

审核日志应主要关注用户的唯一标识符 (UUID)，而不是其个人详细信息。

要在应用程序报告中显示上次更新的信息和用户详细信息，请根据唯一用户 ID (UUID) 在审核日志和用户数据之间执行联接。