基本概念

先看看这篇文章，了解下EOS.IO权限模型的三个基本概念：

• Wallets（钱包）——钱包是EOS.IO提供的用于管理密钥对的客户端，钱包支持锁定和密码解锁。
• Accounts (账户）——账户是公示在区块链上的人工易读（不是公钥或短地址！！！）的名字。
• Authorities and Permissions(权限及授权验证）——每个账户都内置owner和active权限，owner冷藏用于恢复其他权限。

权限（Permission）定义的目标

EOSIO的账户权限定义的目标在白皮书中这样叙述:

EOS.IO software allows each account to define a mapping between a Named Message Handler Group of any account and their own Named Permission Level. For example, an account holder could map the account holder's social media application to the account holder's "Friend" permission group. With this mapping, any friend could post as the account holder on the account holder's social media. Even though they would post as the account holder, they would still use their own keys to sign the message. This means it is always possible to identify which friends used the account and in what way.

这段话明确了EOSIO允许账户持有者部分让度权限，而且权限受让者是用自己持有的密钥签名，以便明确区分授权行为是如何发生的。

账户(Account)如何生成

权限是建立在账户的基础之上的，那么账户又是如何产生的呢？
首先要明确的一点是：
无论账户还是权限，它们一定是通过签名交易（signed transaction）来定义并在区块链中公示的。——这是其他节点在执行合约时进行权限验证（Authorities）的基础。

来看看利用EOSIO的命令交互，如何生成一个新账户：
$ eosc create account inita tester EOS4toFS3YXEQCkuuw1aqDLrtHim86Gz9u3hBdcBw5KNPZcursVHq EOS7d9A3uLe6As66jzN8j44TXJUqJSK3bFjjEEqR4oTvNAB3iM9SA
命令的说明及返回在这里
返回JSON文本比较长，不过读懂它的每一部分含义你也就理解了EOSIO权限模型的设计思路。这里我们先看看与本文相关的几处：

• 每个账户默认携带owner和active两个权限，分别对应一对密钥（*其中owner密钥冷藏保存，通常用active来干活，方便用owner恢复active）
• 该命令用账户inita的active权限签名提交了一个交易
• 交易调用了内置合约eos的newaccount行为
• 命令传入的公钥分别作为新产生的tester账户的owner和active权限公钥

这里一定有人会问：那么这个最初的账户inita是由什么账户来签名生成的呢？——它是在启动区块链时，在创世区块的配置config.ini中直接定义的。
参考文档在这里

权限（Permission）如何定义

上面我们看到，对于账户默认携带的owner和active权限，只需要在建立账户时指定就好。那么账户如何自定义权限呢？
看这里 后续的Create or Modify Permissions 章节。
权限定义的关键在于那个描述权重的JSON：

{
  "threshold"       : 100,    /*An integer that defines cumulative signature weight required for authorization*/
  "keys"            : [],     /*An array made up of individual permissions defined with an EOS PUBLIC KEY*/
  "accounts"        : []      /*An array made up of individual permissions defined with an EOS ACCOUNT*/
}

• threshold给出满足此权限验证至少要达到（当然比它高也满足验证）的权重。
• keys 定义了在本权限定义中，可获得的权重的密钥集合。
• accounts定义了可获得权重的账户+权限公钥签名集合。
  即是说，后两者是以不同的形式给出可获得权重的签名集合，实施中可根据具体情况灵活运用。
  另外可以看出，目前的权限定义采用了覆盖的形式，即：对同一权限的重复定义，后者会覆盖前者。