README

PolyAuth 是一个独立于任何框架和数据库的 PHP 认证和授权库。

注意：此库尚未准备就绪！仍需修复一些错误。如果您发现任何错误，请确保在问题中告诉我。但它正在积极开发中。

依赖

• PHP >= 5.4.12
• PDO + MySQL 或任何存储适配器
• leighmacdonald/php_rbac
• ircmaxell/password-compat
• PHPMailer/PHPMailer
• php-fig/log
• tedivm/stash

功能

• 认证流程实现：HTTP Basic、HTTP Digest、Hawk、Cookie、OAuth 1 & 2 消费者访问代理、OAuth 2 提供者、OpenID 消费者和个人消费者。
• 用户账户管理（包括账户封禁）- 确保您的身份是唯一的，如果您使用身份作为显示名称，请不要允许重复的显示名称。您可以混合用户名和电子邮件，使电子邮件成为身份，用户名成为显示名称。
• NIST 级别 1 的基于角色的访问控制
• 基于 Bcrypt 的密码加密
• 自动发送激活和忘记身份/密码的电子邮件（可以关闭并手动使用（SMTP/mail 支持））
• 使用支持 PSR 日志接口的日志记录器
• 可扩展到许多后端的自定义会话处理
• 会话对象的操作，例如添加购物车。
• 会话文件的文件锁会自动通过关闭句柄立即解决。这可以防止 AJAX 竞态条件。
• PSR 1 兼容且框架无关
• 基于 PDO 的数据库查询（目前仅限 MySQL）（如果使用 Codeigniter，请使用 $this->db->conn_id）
• 登录和注销
• 基于指数超时的可选登录限制（超时 = 1.8^(尝试次数-1)），这可以设置为 IP 地址、登录身份或两者。使用每种方法都有优点和缺点。
• 使用各种认证策略自动登录。
• SQL、Codeigniter 和 Phinx 迁移
• 可配置的返回错误语言
• 通过扩展自 "PolyAuthException" 的异常处理错误
• 高度可配置的用户数据/配置文件
• 密码复杂度检查
• 出色的随机令牌生成器
• 通过 Travis 的持续集成进行单元测试，因此您可以信任它的工作！
• 支持数据库无关功能的存储适配器

待办事项

• 添加 OpenId 配置 & OpenId 代理 & Persona 配置
• SQL 迁移，Phinx 迁移
• 添加 Redis 持久性
• 添加更多存储适配器
• 添加一个命令行工具，允许操作RBAC（如创建角色/权限和执行所有AccountsManager能做的操作）。它应该能够解析RBAC JSON配置文件（可能是YAML或JSON，肯定不是ini文件）。这应该支持层次结构（即2级RBAC）。使用https://github.com/nategood/commando作为二进制文件。甚至可以编译成phar！这将需要数据库访问，所以我们需要传递一个相关的存储适配器？可能是指向一个文件，或者命令行选项，还需要指向相关的选项来使用。关于polyauth_conf.json（覆盖选项和数据库选项），以及polyauth_rbac.json（处理权限层次）。//Cookie策略容易受到CSRF攻击。但是当你有HTTPONLY时，它不容易受到XSS攻击。//授权头不容易受到CSRF攻击。但是它容易受到XSS攻击！
• 需要具有询问用户是否具有这些角色中的权限的能力（这不是指所有用户拥有的角色，而是仅指特定类型的角色）。如果用户自己也可以为其他用户创建角色以访问其资源，这可能很有用。
• 关于OAuth2服务器：https://github.com/php-loep/oauth2-server和https://github.com/bshaffer/oauth2-server-php
• 降低PHP版本要求到5.3（需要进行一些测试）
• 简化存储适配器

忘记密码检查和重置密码有一些需要更改的地方。

1. 忘记密码功能会自动通过emailer发送邮件。需要有一种方式将其设置为手动。以便在必要时允许用户自己发送邮件。
2. 忘记密码功能有点过于复杂。它应该只是将密码重置为随机密码，并将其发送给通过电子邮件发送。
3. 重置密码应直接进入数据库源，它不应该调用change_password，因为change_password可能会抛出异常，如果随机生成器不够随机。整个邮件发送流程需要彻底翻新，因为邮件发送没有意义。它应该可选地插入并实例化，带有传递给类的任何模板。它不应该成为选项表的一部分。

LoginPasswordComplexity需要是可选的，只需设置false！

所有查询都应该有一些排序选项！

UserAccount::authorized需要实现范围和所有者。

需要通过使用PDO中的inTransaction布尔值来补偿嵌套事务。在尝试开始事务之前，询问是否处于事务中。

添加实现私有云的可能性。PolyAuth的私有云版本。这样数据库中的数据就完全加密了。基本上是PolyAuth的虚拟应用。

用户帐户应该实现__clone、__toString和__serialise以及任何其他魔术方法。一种简单的方法是导出所有用户帐户数据。由于用户帐户实现了数组接口，它也应该实现可遍历接口...等等。用户数据需要预先加载角色和权限。一种方法是使用一个“roles”数组，包括所有角色以及层次结构角色。也许本质上它是层次结构的？还有“permissions”数组，包括从所有继承的角色计算出的所有权限。目前这两个属性并没有添加到用户对象中，而是隐藏在父对象中。我们需要将此数据传递给客户端（AngularJS），以便AngularJS可以根据其角色和权限在UI中显示或隐藏内容。当然，一切都要经过双重认证。首先在UI上检查用户是否已登录以及是否有必要的角色/权限/范围，然后在请求查看或修改数据时，在服务器端再次进行认证。服务器端持有主状态，是最终的裁判。但是客户端需要能够根据自身判断显示或隐藏某些内容，以帮助用户体验。你不能发送AJAX请求来询问是否可以显示内容，所有角色和权限都会在用户登录后立即加载。

应该使用phpseclib进行加密，这样就可以在没有mcrypt扩展的情况下工作！加密算法不够安全。请参见以下示例：http://au2.php.net/manual/en/function.mcrypt-encrypt.php

对于QueryToken策略

1. 需要一个与autoCode分开的queryToken字段，因为autoCode始终与CookieStrategy的autoCode相关联，并且不能自动刷新。
2. 每次有人登录且URL参数中包含?query_token=字段时，都需要重置queryToken。即使queryToken策略没有激活。这是因为如果queryToken在URL上保持相同，这本质上是在公开一个临时密码，如果有人窥视或有人忘记关闭浏览器，就会暴露。因此，重置逻辑需要在认证器策略中实现。此外，这些queryTokens也应该像autoCode一样有有效期。也许queryDate？
3. AccountsManager需要重置queryToken和queryDate以及重置autoCode和autoDate的能力。
4. AccountsManager/Authenticator需要能够注销所有人，通过销毁所有会话、所有访问令牌、所有autoCodes、所有queryTokens、所有IP授权和所有用户代理设备授权。此外，它还应该能够为单个账户执行此操作。这在账户被入侵时非常有用。这需要SessionManager获取所有会话并找到与特定用户ID匹配的会话。

PolyAuth应该标准化选项类，并使用它来存储所有选项，以保持一个地方。研究更好的呈现方式，也许可以使用像Symfony Options这样的东西。设备跟踪使用用户代理，并将处理空用户代理的情况。空用户代理应被视为可疑。但会有不同的可疑级别：最高可疑，阻止未添加到批准用户代理列表中的所有用户代理。或者高，阻止未识别的主要浏览器或类似浏览器（如用户始终使用Firefox的不同版本的Firefox！）的用户代理。一切都可以有一个白名单。甚至可以设置ip地址和用户代理之间的规则。当然，阻止来自以前登录的所有ip地址！

请记住建议使用 GEO-IP2 来查找 IP 地址的位置。如果需要确定 IP 地址不在同一位置，使用 Geo IP 会更好。我们可以直接禁止所有不同的 IP 地址。但请记住，如果人们使用动态 IP，这会成为一个问题。因此，基于城市的跟踪位置将更加宽松，但需要 GEO IP 扩展插件。https://github.com/maxmind/MaxMind-DB-Reader-php

即使有 composer，也要为每个库提供自动加载器。Dragoon 还需要一个能够自动加载外部模块的自动加载器，并注册 PSR-4 和 PSR-3 模块，以防它们被引入源代码中。此外，减少简单的外部依赖。我认为 PolyAuth 不需要 PHP Mailer，应该有返回电子邮件数据的函数。还应为 PolyAuth 提供使用 ~ 运算符的变量依赖关系，以便某些依赖关系。想象一下，有人注册，而不是自动发送电子邮件。如果你想要发送电子邮件，请调用函数 get_activation_data/email()，这将返回一个与激活某人相关的数据数组。

绝对要添加 IP 地址位置跟踪和双因素登录！多设备跟踪也。多因素登录。比如通过新 IP 或新设备登录。

使用下一个重要的发布版本来处理 composer 依赖项！~ https://getcomposer.org.cn/doc/01-basic-usage.md#next-significant-release-tilde-operator-

支持客户端证书认证/双向认证策略：http://nategood.com/nodejs-ssl-client-cert-auth-api-rest http://blog.nategood.com/client-side-certificate-authentication-in-ngi http://cweiske.de/tagebuch/ssl-client-certificates.htm http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/（客户端证书认证是为了增强密码使用，而不是替代密码使用。因为原生的双因素认证涉及到你拥有的东西和你知道的东西。这意味着无密码 SSH 实际上更不安全。最好的做法是将你必须拥有的证书和你知道的密码结合起来。以这种方式，这种策略可以允许无密码登录或带密码登录！）http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts

多设备认证。

跟踪设备登录统计。

跟踪一般登录统计。

可以从不同的设备进行授权，并在从新设备登录时通过电子邮件进行警报。然后跟踪设备。

http://blog.authy.com/multi-device

就像 steam guard + gmail！

添加sudo模式。允许对重要操作进行重新认证：https://help.github.com/articles/sudo-mode

使用 HMAC 客户端令牌。这比在服务器端存储令牌要好得多：http://lucumr.pocoo.org/2013/11/17/my-favorite-database/令牌可能仍然需要存储在服务器端，但现在相关信息，如过期日期，可以存储在客户端！实际上，可以将令牌简单地存储为用户的加密版本。获取 ID，然后你知道这个令牌适用于哪个用户！

使用 hhvm 进行测试。PolyAuth 服务可能需要 hhvm + Dragoon。

language: php

php:
  - 5.3
  - 5.4
  - 5.5
  - hhvm

script:
  - phpunit --coverage-text
  - phpunit --group unicode --coverage-text

matrix:
  allow_failures:
    - php: hhvm
  fast_finish: true

未激活的账户不应被阻止登录。许多网站在账户正式激活前允许部分访问账户，甚至可以设置相关设置。或许可以设定一个时间限制，如果账户还未激活，则自动删除（不能被禁用）。我们需要有一个状态列来指示主要状态。激活 - 禁用 - 未激活 - 删除（软删除） - 待定。或者这些可以创建为角色，并分配给用户。RBAC 应接管这一部分。从意义上讲，如果一个账户未激活，那么它将缺少某些权限。

账户合并，当有两个账户时，可以将所有权合并并将账户代理到主账户。

激活：四种方式

1. 防止登录 - 选项或 RBAC（事实上，可能可以有一些登录回调...？）
2. 允许完全访问但需要在一定时间内激活 - 重新实现
3. 除非完全激活，否则防止使用某些功能 - RBAC
4. 如果用户更改了电子邮件地址，账户是否仍然激活？我认为更改电子邮件地址需要重新验证电子邮件，除非你不在乎。在大多数情况下，更改电子邮件地址需要确认该电子邮件，因为更改已提交。

需要有一种简单的方法来确定用户是否拥有特定的资源？通常只有在用户拥有特定资源时，才能执行某些操作，这也可以发生在资源集合中。例如，能够删除资源集合中的资源。

解决这个问题的方法是创建一个 auth_resources 表

（id 可能对于这个 auth_resources 表不是必需的，因为用户是 1 到 1 的关系）这也意味着你不需要在其他表上使用任何 userId 列。（移除了 id，让我们保持简洁）| userId（主索引）| blogIds | logIds | commentsIds | resIds... |

1                         {4}      {2,4}        {78}         {9}... (the {} is serialized)

这是一个关系表，在 users、collections 和 resources 之间创建多对多对多关系。记住这和 OAuth 委托资源请求没有任何关系。多个用户可以拥有同一资源。在这种情况下，你必须检查其他表中的关系实体，例如访问令牌表。因此，这是一个用户将访问令牌委派给其他用户的表...等等

User1 - - CollectionA - Resource76 \
\ Resource89
\ Resource12（User1 和 User2 共有） \ / CollectionB - Resource25 / User2
CollectionC - Resource4

在创建、删除或更新集合时，auth_resources 表中会创建相应的列。

这允许我们建立用户之间的资源关系所有权。

允许请求验证变得简单

$this->user->authorized([ 'owners' <-- 我认为这实际上是指委托请求，基本上你知道资源的所有者是谁，然后检查用户当前是否有权访问这种所有权，无论是作为用户本身，还是作为委托访问，需要一个更好的名字！'resources' => [ (AND BASIS) 'blog (resource)' => id OR 'blog (resource)' => [id, id] ] ])

OR

resources => ['blog#4', 'log#9']

OR

resources => 'blog4'

这意味着你可以在多个请求中这样做

if($this->user->authorized([ 'roles' => 'admin' ], [ 'resources' => 'blog#4' ])){

//proceed with the knowledge that the user either is an admin, or owns the 4th blog post

}

所有表都需要在 auth_... 等等下标准化。

此外，在启动时，这些内容将在用户账户对象下解析和加载。

foreach($resources as $key => value){ $key ---> blog..等等 $value ---> unserialize($value) ---> [4, 5, 6, 7, 8] }

AUTH RESOURCES 应使用 CLOSURE TABLE 方法。这是 MySQL 最好的方法。 http://www.slideshare.net/billkarwin/models-for-hierarchical-data

顺便说一句，我们应该转向使用 Collection 对象而不是数组。

现在更新 auth_resources 表需要两个步骤，要么增加更多列来表示资源（有限的），要么向特定集合添加更多 ID。这应该通过 accounts_manager 类来完成。因为 user_account 对象是临时的，它是一个副本而不是对已保存的 user_account 对象的引用。

也使用 json_encode/decode 而不是 serialize/unserialize。编码更快，解码稍微慢一点，但 json_encode/decode 的大小要好得多，而且它也易于其他语言读取和处理。

层级 RBAC 可以转换为层级对象命名空间权限。这允许角色与多租户（如组织）交换。不再检查角色或权限，而是只需检查权限 => 'role.subrole.permission'。层级权限！由于权限是命名空间化的，它们可以具有相同的名称。因此可以为其构建一个 UI。

SessionManager 应该使用 Cache 接口，如 PoolInterface 和 DriverInterface。关键是 SessionManager 需要一个持久对象。持久对象可以是 SessionPersistence。这个对象请求一个 Stash\Interfaces\PoolInterface，即要放入的缓存。这最终应该标准化为 PSR-6 缓存接口。就是这样。我们将设置缓存的复杂性和灵活性转移到最终用户。所有内容都应该是基于 DI 和接口的，不再创建默认依赖项。不是请求一个 Options 对象，而是一个数组。需要全局选项时传入全局选项，需要特定选项时传入特定选项。此外，集合对象会更好！因为你可能会有类似宽松数组访问的东西。

删除 Emailer，而是创建一个包含 Notification 接口的 Interfaces 文件夹，允许 PolyAuth 以任何他们想要的方式通知人们。

创建一个包含 Options 和 Language 的 Config 文件夹。

创建一个包含 LoggerTrait、Random 等工具的 Utilities 文件夹。

临时令牌（如 Autologin 令牌、忘记密码令牌、临时登录令牌）应移动到单独的表中。这些是临时的，因此它们甚至可以放在类似 Redis 或其他缓存系统中。

注意 OAuth 令牌是永久的，因此需要将其放入安全的数据源。

使用 Composer 安装

"polycademy/polyauth": "*"

测试

使用 Codeception 的 --defer-flush。

注意

确保 session_save_path() 是可写的！

这不会对数据输入进行过滤或验证。你仍然需要这样做以防止出现任何问题。这不会进行 CSRF 检查。我不认为这应该是用户认证系统的一部分。这也不会强制你或检查 SSL，这应该是你的工作！

授权头需要可供 PHP 运行时使用。Apache 和 Fast-CGI 将会工作。然而 PHP-FPM 目前不支持 getallheaders()，但大多数 web 服务器（如 NGINX）将传递授权头。如果你很小心，只需检查 HTTP_AUTHORIZATION 是否存在于你的 $_SERVER 全局变量中，如果没有，你需要在 web 服务器的配置中手动设置它。使用非 HTTP 基本授权头进行测试。它可以是 Authorization: Lol。

计划

账户联盟/合并绝对需要。特别是如果一个人创建了两次相同的账户。将设置一个作为先例，另一个作为合并。

使用新的集合：[https://github.com/schmittjoh/php-collection/pull/15](https://github.com/schmittjoh/php-collection/pull/15)

链接： https://php.ac.cn/manual/en/spl.exceptions.php https://github.com/schmittjoh/php-option http://jmsyst.com/libs/php-collection http://jmsyst.com/libs/serializer https://symfony.com.cn/doc/current/components/options_resolver.html www.slideshare.net/billkarwin/models-for-hierarchical-data (与用户相关) https://github.com/piwik/device-detector/issues/1

用户的状态机（FSM）

已注册 - 初始状态 未激活 - 正常状态 已激活 - 正常状态 被禁 - 最终状态

已注册 -> 已激活 => 激活中 已注册 -> 被禁 -> 禁用中 已注册 -> 未激活 -> 注销

未激活 -> 已激活 => 重新激活 未激活 -> 被禁 -> 禁用中

已激活 -> 被禁 -> 禁用中

跟踪的状态机（FSM）

未确认（初始状态） -> 已确认（最终状态） => 确认中

我们需要一个无状态的邮箱激活模型！

无状态解决方案

Take email of the user and sign it cryptographically
Send email to the user with the link to our website containing the signature
Once user has clicked the link in the email, verify digital signature and if it's valid, we confirm his email

这可以应用于每个令牌。然后我们不需要数据库字段来保存令牌的状态！

基本思想是，PolyAuth有一个私有密钥和“未知”的加密算法，它使用密钥对电子邮件地址进行加密并签名。当签名的加密信息返回时，我们解密它，并检查我们的系统中是否存在该电子邮件。我们甚至可以对其附加额外的参数，如时间戳，这可以确保代码只在特定时间段内有效。 http://lucumr.pocoo.org/2013/11/17/my-favorite-database/ 我认为用户ID也需要包含在有效载荷中。也许...

备注

pa_identities - 主题及其永久性配置文件数据 + 用户状态。其他任何内容都应该存储在其他地方。这包括所有者和客户端，这意味着所有者和客户端都是主题。pa_tokens - 长期有效的令牌（忘记密码、激活、一次性登录令牌）。所有这些令牌都有过期时间。每个令牌都与一个userId相关联。忘记密码和激活令牌是一对一。一次性登录令牌也可以是一对一，或者一对多。pa_providers - 列表：id、userId、providerName、providerUniqueId、一个身份对应多个提供者（意味着联盟提供者）。每个提供者记录与access_delegation记录（这将始终是一个外部访问令牌）一一对应。由PolyAuth配置的身份不会在此记录。pa_roles - 角色是执行组织中的特定功能所需的一组常用权限。角色也是作用域。角色分配给主题。pa_permissions - 权限在此设置并由资源调用。它们分配给角色。pa_access_delegation - 包含与所有者（身份）、客户端（主题）和提供者（可以是PolyAuth本身）相关的访问令牌。每个身份都可以有作为所有者的访问令牌，但也可以有作为客户端的访问令牌。这意味着身份可以委托其他身份访问，也可以从其他身份处获得委托的访问权限。pa_security_log - 记录并记住用户的行为。这可能包括pa_associations -> 闭包表，将主题与令牌、提供者、角色、角色与权限、主题与access_delegation、到security_log关联。pa_tracking -> 登录跟踪，每次有人登录时，我们会获取他们的指纹，并与之前的指纹进行比较。如果它们不匹配，我们将引发一个异常，这可以通过处理来通知。就像Steamguard一样。而且我们也不能匹配精确的IP地址，尽管这是可能的，但最好使用国家。

1. 登录尝试数据pa_login_attempts => 转换为缓存。现在我们必须存储所有登录尝试，但也可以清除它们。此外，登录尝试可以通过身份、IP地址或两者来发现。
2. 会话数据pa_sessions => 转换为缓存（这是特定请求的服务器端会话数据，如果保留会话ID，则保留会话数据，请注意，会话数据也可以很容易地从客户端端实现）

电子邮件

1. 如果它们是唯一的记录：a) 当需要使用密码登录时，会使“登录”容易得多 b) 意味着任何人尝试通过第三方提供者登录时，如果提供者提供了相同的电子邮件地址但没有相同的提供者ID，则不会创建账户，而是抛出一个异常。开发者应该登录到他们以前的账户并合并账户。如果以前的账户是一个外部提供者的账户，他们可以使用忘记密码，这将生成一个。除非电子邮件不存在，这在Twitter的情况下可能是真的。在任何情况下，保证路径是通过第三方再次登录。除非第三方不再存在或不可操作。在这种情况下，需要升级，管理员需要更改此账户。具体来说，是通过添加电子邮件，并允许人们“忘记”密码。c) 正常注册不允许重复的电子邮件。
2. 如果它们不是唯一的记录：a) 使用电子邮件登录会更加困难。这要求我们区分可登录的账户和不可登录的账户。这意味着必须有唯一的电子邮件和密码组合。也就是说，两个身份不能有相同的电子邮件和密码。因此，如果有相同电子邮件但没有密码或密码不同的身份，则无法登录。不允许相同的密码与相同的电子邮件一起使用，这将在个人资料编辑阶段/密码生成阶段/密码更改阶段阻止。b) 使用第三方提供者登录很容易。c) 正常注册允许重复的电子邮件，或者不允许重复的电子邮件……这取决于。如果您使用OAuth，那么您应该防止重复的电子邮件。

如果您不使用电子邮件作为登录身份，则此内容无关紧要。也就是说，电子邮件不需要是唯一的记录，而且您也不会使用电子邮件登录。

上述内容也适用于用户名。除非用户名是唯一的，那么您不需要防止创建账户，但可以通过添加随机后缀来修改用户名。

还可以有“显示名称”。

最简单的解决方案是

1. 电子邮件是唯一的

转换为PSR-4 添加引导程序？

开发HRBAC

此外，Options类实现了Config类。我们需要为此添加类型提示，以便可以输入数组对象。

所有集合都实现为集合。当传递给对象时，它们需要通过iterator_to_array()进行传递。

所以，配置和语言将基于Config对象。

期望配置的对象不进行数组类型提示。相反，它们会检查对象是否可遍历。

如何呢？

Configular读取配置。Options对象接受Configula，并将其映射到集合对象。期望选项的对象将检查它是否是数组或可遍历的。如果是可遍历的，它将在继续之前将其转换为数组。然后也使用OptionsResolver。一切都是注入的。

关于电子邮件地址甚至用户名。因为我们不能相信远程服务来确保主题确实拥有特定的电子邮件地址，并且不同的提供者将会有使用相同电子邮件地址的主题，甚至可能还有相同的用户名。我们将为每个唯一的providerId创建一个新的身份。这意味着获取基本数据，如用户名和电子邮件数据，并将它们添加到身份数据库中。这意味着可以有多个具有相同用户名和电子邮件地址的身份。这会影响密码登录和密码注册。

1. 密码登录根据“任何一个”规则操作。它会检查是否有匹配登录身份的记录，如果有多个，它会检查密码是否与其中任何一个匹配。

相互SSL认证！https://codeproject.org.cn/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

Kato注册/登录流程

1. 请求电子邮件
2. 发送激活（无状态风格）
3. 允许立即使用（定时激活，重复提醒激活，每次使用时激活）
4. 允许重复激活
5. 使用期间无需激活的密码无会话
6. 一旦激活，就请求密码（在激活时和登录时（使用电子邮件））

缺少的东西：社交登录、Open ID、可组合的认证……也许可以通过社交登录，可以跳过所有这些，立即使用应用程序，同时允许用户稍后设置密码和电子邮件地址（在设置时确认电子邮件地址）

用户状态机

已注册 -> 激活 -> 已激活 -> 禁用 -> 被禁用 -> 激活 -> 未激活 -> 重新激活 -> 已激活 -> 禁用 -> 被禁用 -> 禁用 -> 被禁用

OCR模型

所有者对客户端和资源进行身份验证。客户端对资源进行身份验证。资源代表所有者授予客户端访问权限

O - 所有者 - 一个用户 C - 客户端 - 一个用户 R - 资源

授权码：O - Roger C - PolyAuth R - Facebook

隐式：O - Roger C - PolyAuth (公开运行) R - Facebook

资源所有者密码：O - Roger C - 单页应用（客户端应用）R - PolyAuth

客户端凭证 O - SPA C - SPA R - PolyAuth

不使用OAuth O - Roger C - Roger的HTTP客户端（未知）R - PolyAuth

每个访问令牌都是客户端、所有者和资源之间的一种独特关系。每个访问令牌都由客户端持有。客户端可以有多个访问令牌。每个访问令牌都有一组特定的作用域，与特定的所有者和资源相关联。资源根据客户端的角色 + 权限以及根据访问令牌关联的所有者的访问令牌的作用域授权客户端。权限层次结构由以下定义：客户端访问令牌（作用域 + 用户）＜客户端角色 + 权限。访问令牌的作用域 + 用户被客户端的角色 + 权限覆盖（覆盖）。

权限模型

所有权限都来源于

C - 写权限 R - 读权限 U - 更新权限 P - 补丁权限 D - 删除权限

它们应该通过二进制数字进行编码。所以你可以做 C & R 等等。

每个资源都可以有多个权限。每个资源都可以有子资源。每个资源都可以有抽象资源。资源像有向图一样进行操作。（图数据库）分类抽象资源的权限映射到子子资源。

因此作用域只是相对于特定用户账户资源的权限。用户账户是非常抽象的资源，因此包含许多子/子资源。例如用户的评论、用户的博客文章。子资源继承父资源。因为资源是图模型，每个资源可以成为许多父资源的层次结构子资源。例如，博客文章可能属于博客资源，但每个博客文章都是由用户创建和拥有的，因此它们也属于用户X的博客资源，其中X是特定的用户ID。因此，这是多对多图模型的层次继承：http://blog.neo4j.org/2010/03/modeling-categories-in-graph-database.html 这意味着不可变图数据库是建模此结构的最佳工具。其他数据库可以存储时间域表示，当你需要更高的效率时（例如，当我们将MySQL的行模型转换为对象模型时）。我推荐Neo4j或FoundationDB。

这意味着角色只是指定多个权限的便利包装或语法糖。打包权限。

给定一个资源图模型，可以在有向图中设置事务。这应该非常无缝，因此如果一个图中的资源遇到异常（可能是因为不允许的权限），则应该抛出异常（这可能需要通过包装器、异常静态类来完成，这将检查管道是否已事务化或部分事务化，如果已事务化，则应该硬失败并回滚一切，如果部分事务化，则应该软失败，忽略并继续下一个独立操作）

好的，让我们假设我们的资源在图中。现在每个资源都有其CRUPD权限集，这不需要保存，模型是动态指定在代码中的。

客户端是持有权限（及其相关角色）的对象。如果它们有角色，这些角色会自动展开并合并为一组权限（顺便说一下，所有权限都是唯一的，因为CRUPD始终与单个资源相关联）。现在他们本质上拥有的就是R1:CRUPD，R2:CRUPD，R3:CRUPD。但不是指定低级别的RX，这些RX可以是高级资源。记住权限是分层的，因为子资源权限继承自父资源权限。所以比如说，如果我给阅读博客文章的权限，即BLOGS:R，这意味着用户也可以阅读博客文章1或博客文章2，所以BLOGS:R意味着BLOGS->BLOG1:R和BLOGS->BLOG2:R。除非BLOG2要求必须具有“严格”的读取权限，这意味着用户必须严格为此拥有读取权限。这减少了存储大小，因为我们不需要记住客户端拥有所有子权限，而只需要记住高级权限，当请求权限时，简单地遍历继承链。

因此范围和权限合并了！角色只是范围和权限的语法糖，可以分配给客户端或访问令牌！它们最终扩展为权限。

新的PolyAuth

一个微服务认证服务。

使用purescript + io.js吗？

引入passport和一些形式的RBAC。权限驱动器。

加载到Docker中！

第一阶段包含其自己的状态。

第二阶段是无状态的，依赖于外部状态自动机。这将是一系列可选的自动机。

我们如何处理改变父类型的选择性依赖项？

也许它们不应该，因为配置是在那里选择使用哪些选择性依赖项。

复合认证是我曾经做过的最酷的事情之一。它对cookie/http基本工作得很好。