1.兩者都是基於角色的訪問控制。
2.同壹個用戶可以屬於多個角色或用戶組。
差異:
Rbac:
1.Rbac是基於節點控制的。根據節點的三個層次，模塊、控制器、動作、節點相似度和樹形結構，三個層次的節點是相互關聯的。
2.表關系:用戶表-& gt；用戶角色關聯表->；角色表->；角色節點關聯表->；節點表
3.按照三級節點控制，從粒度到操作動作，每個節點都是單個模塊、控制器或操作。
授權:
1.Auth基於規則控制、自定義規則和條件表達式，每個規則都是獨立的。
2.表關系:用戶表-& gt；用戶和用戶組關聯表-& gt；用戶組表-& gt；規則表
3.根據規則控制，可以自由定制不同的規則，非常自由。在同壹個規則中可以定制很多不同的節點(中間關系:OR AND)。
4.可自定義的正則表達式，如自定義的積分表達式。
想法和問題:
授權:
1.驗證多個規則時，驗證條件表達式無效。
2.2的官方例子。Auth只說壹個基於積分的規則，如果我規則“admin/goods/goodslist，admin/goods/goods del”I。
能否定義壹些ID所屬角色的操作權限的正則表達式，這些ID屬於商品表中的壹個字段，可能屬於幾個不同的角色？
3.Auth不支持“Admin/*”泛解析，因為每個規則都是獨立的。
4.使用Auth來顯示菜單、頁面和按鈕將會更好、更方便。
Rbac:
1.新手配置Rbac時，經常會出現無法獲取Rbac $_SESSION['_access_list']的問題，因為Rbac是使用ThinkPHP的底層DB引擎DSN連接數據庫的，需要配置數據庫鏈接和五個表的關系，不能有字段名和表名的問題。
2.允許完成“Admin/*”類型的泛解析，比如在這裏直接自定義Admin模塊的壹個節點，不要隸屬節點。
常規:
1.Rbac的角色表和Auth的用戶組表都可以擴展，比如角色或用戶組的多級分級。
2.Rbac節點和授權規則可以分級，比如前端功能權限，後端功能權限，後端功能模塊權限。
3.以上兩件事不能應用於權限控制。比如Rbac不能共享上級角色的權限，auth用戶組也不能，但是可以用更精簡的方式更好的管理和操作。