You’re probably dealing with this already. The app login works, users can sign in with Google, Microsoft, or email, and the API accepts a token. Then the core questions begin. Can this user see invoices from another account? Should the desktop app cache an access token locally? How do you handle consent in a Capacitor build without leaking state across the webview and native layer?
Capacitor
目录
应用授权的真正含义
用户安装了您的应用，点击“继续使用 Google”，成功登录，然后出现一个同意屏幕，询问应用是否可以读取联系人或日历数据。这个瞬间包含了访问的两面。登录确认了用户的身份，同意屏幕定义了应用在身份已知后可以做什么。
团队仍然会因为这个区别而迷惑。 身份验证 确认用户的身份。 认证 决定用户、会话或应用程序可以访问什么。一个 ID 可以让你进入大楼。一个密钥决定哪些门可以打开。
在应用程序工作中，这个区别很重要，因为团队经常安全登录流程，然后在此之后的设计不足。他们过度信任令牌，跳过服务器端权限检查，或者让客户端驱动访问规则，这些规则应该在策略中存储。这样，“用户已登录”会悄悄地变成“用户可以访问太多内容”。
认证是信任变得具体的地方。用户不仅关心你的应用程序知道他们是谁。他们关心它只触摸他们批准的内容。
需要记住的三个角色是:
- 用户 签名并可能授予同意。
- 应用程序 代表用户请求访问。
- 资源所有者或API 保护数据并执行决策。
在实践中，应用程序授权也与更强大的访问控制，如 MFA 重叠。截至 2023 年 1 月, 全球用户中约有 66% 使用了 MFA, 和 超过 1,000 名调查的中小企业 IT 专业人员中有 83% 需要 MFA 访问公司资源 根据 JumpCloud 的 MFA 统计总结. 这并不会取代授权，但它确实提高了谁可以要求访问的基线。
如果您的团队正在处理角色、范围和委托访问的问题，这里关于 应用访问管理模式 的概述是一个有用的补充。
授权的基本组成部分
授权会变得更容易一旦您停止将其视为令牌内部的神奇事物。更好的思维模型是酒店。
酒店卡是好的思维模型
一个游客走到前台，展示身份证。酒店验证身份，创建入住记录，并发放一张钥匙卡。这个卡片并不能证明游客的身份每次门被打开时。它携带着在有限时间内访问特定地方的许可权。
您的应用程序与此类似。
重要的是，卡片本身并不是策略。它反映了策略。门仍然需要一个系统来检查卡片是否应该打开特定的锁。 在软件中，这就是您的API网关、后端中间件、策略引擎或服务级别授权层。
在实际系统中，以下术语很重要
主体
请求访问的主体。通常是用户，但也可以是设备、后台作业或服务账户。
资源
被保护的东西。一个项目、发票、管理员路由、文件、API端点或数据库中的一个记录。
范围
范围
请求的操作集。读取个人资料。上传文件。管理账单。范围应该是狭窄的和易于理解的。
用户对请求的访问级别的同意。好的同意屏幕使请求可读。坏的会要求所有内容。
访问令牌
客户端在授权成功后向资源服务器呈递的凭证。它应该被视为敏感数据。
很多实现错误来自压缩所有这些信息到一个单一假设：‘用户有令牌，所以让他们进去。’但这在生产环境中并不成立。令牌可能是有效的，但仍然不适合当前的动作、租户、环境或资源。
对于移动和桌面团队来说，令牌处理需要特别关注，因为存储是授权系统的一部分，无论你是否喜欢。 如果客户端不小心存储访问艺术品，政策设计在后期也无法救你。 在您发布之前，值得浏览的关于 移动开发人员的安全令牌存储指南 的指南。
一个可靠的规则很简单。 在您的头脑中和您的code中，保持身份验证、同意、令牌颁发和服务器端强制分开。 合并它们的团队通常会在错误的层次上调试权限错误。
常见的授权模型和协议
当团队说‘我们正在使用OAuth’时，他们经常同时指代几个不同的事情。这就是混淆的原因。 协议和授权模型解决不同的问题。
协议处理对话
OAuth 2.0 主要是关于委托授权。它定义了应用程序如何请求和接收权限以在不直接处理用户密码的情况下代表用户行动。
OpenID ConnectOpenID Connect（OIDC）位于OAuth 2.0之上并添加了身份信息。在实际操作中，OAuth会回答“这个应用程序可以做什么”，而OIDC会帮助回答“谁登录了”。
在Capacitor和Electron应用程序中，这个差异很重要，因为许多bug都是由于使用ID令牌而不是访问令牌，或者假设登录成功意味着API应该授权所有下游操作而导致的。
如果您正在将其集成到混合应用程序中，请参阅一步一步的 OAuth2实现指南Capacitor应用程序 模型处理决策逻辑
在您的内部系统中，您仍然需要为决定是否授予访问权限而制定规则。这就是
RBAC 和 ABAC 和 欢迎进入.
基于角色的访问控制（RBAC） 将权限映射到角色，如管理员、编辑、支持人员或查看者。它是常见的，因为它是可理解的、可审计的和相对稳定的。根据 BrightSec关于安全认证和授权的讨论, RBAC是行业标准的机制，用于强制实施细粒度的权限,据该讨论中引用的证据表明，使用层次化角色结构和定期权限审计的RBAC 在企业环境中可以降低安全事件的发生率达40%.
基于属性的访问控制（ABAC） 使用属性而不是仅仅角色来做出决定。可以包括部门、设备状态、记录所有权、账户等级、地理位置、请求时间或会话是否通过MFA。ABAC更具表达力，但如果不对策略进行良好的文档化，则更容易变得不透明。
实践规则： 在您的产品权限稳定且可读时，首先使用RBAC。添加ABAC在上下文实际上会改变决策的地方。
RBAC与ABAC的对比
| 标准 | 基于角色的访问控制 (RBAC) | 基于属性的访问控制 (ABAC) |
|---|---|---|
| 核心理念 | 通过角色授予访问权限 | 通过属性评估授予访问权限 |
| 最佳匹配 | 内部工具、仪表板、管理面板 | 多租户应用、受管工作流、基于上下文的访问 |
| 推理的便利性 | 更容易让团队和审计人员理解 | 更灵活，但更难调试 |
| 管理变更 | 添加或修改角色 | 调整策略和属性规则 |
| 常见故障模式 | 角色膨胀 | 策略膨胀和隐蔽边缘案例 |
| 示例 | “支持人员可以查看票据” | “支持人员可以在活动shift期间查看其区域内的票据” |
选择最先进模型并不是什么奖励。更好的选择是您的团队可以一致地执行的选项。在大多数产品代码库中，这意味着使用RBAC进行广泛访问边界，并针对如拥有权、租户或设备状态等例外情况使用目标属性。
OAuth 2.0 流程解剖
很多OAuth 解释太过抽象。对于像Capacitor和Electron应用程序这样的公共客户端来说，序列尤其重要，尤其是那些无法安全地保留客户机密钥的应用程序。
用户点击登录时会发生什么
A user opens your Capacitor app and taps “Login with GitHub.” The app creates a PKCE code verifier and a derived code challenge, then sends the user to the authorization server in a system browser or secure browser tab. The app also includes state so it can verify the response belongs to the request it initiated.
在授权服务器上，用户如果需要则登录并批准请求的访问权限。服务器然后重定向回去带有授权 code，而不是带有长期凭证可以直接使用的凭证。您的应用程序通过配置的重定向 URI 接收了该 code。
应用程序然后将 code 交换成令牌。PKCE 在这个过程中至关重要。应用程序发送原始 code 验证器以及授权 code。服务器将其与之前的 code 挑战进行比较。如果它们匹配，则令牌交换成功。如果有人拦截了 code 但没有验证器，则交换失败。
这就是为什么 PKCE 对原生和混合客户端至关重要。这些应用程序是公共客户端。您应该假设攻击者可以检查捆绑包、逆向工程 code 路径或篡改本地状态。PKCE 缩小了重定向流程中最常见的风险之一。
Here’s a short walkthrough if you want a visual refresher before implementing the sequence in code:
跨平台应用程序通常会在这里出现问题
该协议很简单。实现它的过程并不总是那么简单。
Capacitor 应用程序通常在以下地方失败:
- 使用嵌入式网页签入 而不是系统浏览器。这可能会破坏预期的安全边界并导致 cookie 行为不一致。
- 丢失重定向状态 当应用程序从浏览器恢复到原生壳时。
- 将令牌存储在平坦的浏览器存储中 因为该项目最初是 web 应用程序，团队从未重新审视存储以适应移动设备。
Electron 应用程序有不同的问题。团队有时让渲染进程处理太多的认证逻辑，通过 IPC 暴露令牌而没有严格的边界，或者将桌面应用程序视为受信任的环境。它不是。打包的桌面应用程序仍然需要一个敌对客户端的思维方式。
刷新行为也值得有意识的设计。访问令牌应该过期，会话应该清洁恢复，并且刷新逻辑不应在多个并发请求之间创建竞争条件。这 安全令牌刷新流程指南 是构建该部分而不陷入重试循环或过时会话混乱的坚实参考。
保持 OAuth 握手的习惯比大多数人有用。将 OAuth 握手隔离在一个小的认证模块中，明确输入和输出。不要在组件、钩子和随机网络工具中散布重定向处理、令牌解析和刷新逻辑。
安全威胁和必备最佳实践
授权错误很少在code审查中看起来很戏剧化。它们看起来像方便。这里的广泛范围，那里缓存的令牌，UI 已经隐藏按钮的缺失服务器检查。然后应用发布，这些捷径变成了攻击面。
持续出现的失败
移动生态系统提供一个有用的警告信号。根据 DeepStrike 的移动安全统计数据, 95% 测试的移动应用程序至少失败了一个与身份验证和授权相关的 OWASP MASVS 控制，并且 85% 分析的移动应用程序包含安全漏洞。
标题为《授权安全清单》的图表详细说明了九个保持安全数字应用程序访问控制的必备实践。
- 泄露的令牌 来自不安全的存储、日志、崩溃报告或渲染器可访问的状态。
- 过度的授权范围 因为要求所有内容比逐步演进授权更容易。
- 客户端强制执行 应用程序隐藏未经授权的操作，但API仍然接受它们。
- 重放和重定向攻击 状态、PKCE 或重定向 URI 验证不严格时发生的攻击。
- 授权偏移 团队在没有定期审查的情况下添加角色和例外时发生的偏移。
如果您的后端在每个受保护的操作上都没有验证授权，那么您就没有应用程序授权。您有 UI 提示。
一个实用的检查清单，仍然有效
尽量减少权限,避免后期清理工作。在实际项目中,这意味着缩小每个令牌的作用范围,缩小每个令牌的存储位置,以及缩小每个凭证的有效期。
- 请求狭窄的权限: 只为当前用户正在使用的功能请求所需的权限。如果应用程序可以延迟用户同意,请这样做。
- 在服务器端强制执行: 将客户端视为不信任的。按钮、路由和隐藏屏幕不是安全边界。
- 使用平台安全存储: 在移动设备上,使用native keychain或keystore访问通过插件,而不是普通本地存储。在桌面设备上,将敏感信息保持在易于渲染的范围之外。
- 验证状态和重定向处理: 认证响应必须与应用程序发起的请求匹配。
- 过期激进,刷新谨慎: 短暂的访问令牌限制了当令牌泄露时的损害。刷新逻辑应该清晰地旋转并关闭失败。
- 在需要时撤销: 会话终止和事件响应应包括invalidate令牌和强制重新验证的能力。
- 验证输入并保护传输： HTTPS、适当的证书固定以及输入验证都很重要，因为授权可以通过邻近的弱点绕过。
对于通过商店发布应用的团队，auth设计也与API暴露和合规审查相交叉。这份API安全标准的摘要适合与您的授权清单一起使用。 适用于应用商店合规的API安全标准的摘要 最容易忽略的一个最后一点。最小特权原则也适用于内部工具。管理员面板、支持控制台和测试应用通常拥有公司中最松散的控制，尽管它们经常暴露最敏感的操作。
__CAPGO_KEEP_0__和Electron的实现模式
跨平台应用授权变得更容易了，当您停止假装您的应用只是一个浏览器加上额外的打包时。Capacitor和Electron都需要尊重本机存储、进程边界和重定向处理的模式。
一个专注的年轻开发者在办公室环境中工作着，Capacitor在显示器上。
对于Capacitor，使用支持系统-浏览器OAuth（PKCE）和深度链接或应用链接回调的插件或auth库。类似于
Capacitor模式 capacitor-oauth2 可以移除大量粘合剂 code, 但只有当您仍然保持令牌存储和刷新行为明确时。
实用结构如下：
- 认证协调器： 启动登录，跟踪状态，处理回调。
- 令牌服务： 通过本机安全存储而不是浏览器存储存储令牌。
- API 客户端： 附加访问令牌，刷新一次，然后在不可恢复的失败时强制注销。
- 政策感知后端： 将令牌声明映射到服务器端授权检查。
您还希望session工具与混合应用程序生命周期相匹配。如果您正在评估该层的选项，请查看 __CAPGO_KEEP_0__ 的安全session管理插件。 Capacitor 是一个比较方法的好地方。
A minimal token-refresh shape in pseudocode looks like this:
async function authorizedFetch(request) {
let token = await tokenStore.getAccessToken()
let response = await api(request, token)
if (response.status !== 401) return response
const refreshed = await auth.refresh()
if (!refreshed) {
await auth.signOut()
throw new Error('Session expired')
}
token = await tokenStore.getAccessToken()
return api(request, token)
}重要的不是语法。它是保持刷新集中化，以便每个屏幕不需要自己发明会话行为。
Electron 模式需要额外小心
Electron 需要更严格的边界。尽可能在主进程中保留令牌交换和安全存储。将窄的 IPC 方法暴露给渲染器，而不是将渲染器直接暴露给令牌并希望它遵守。
桌面应用程序感觉更可控。将这种感觉视为风险，而不是保证。
避免这些捷径：
- 不要在渲染器可访问的本地存储中存储令牌 如果可以避免的话。
- 不要让每个窗口共享广泛的认证上下文 而不检查窗口目的和会话生命周期。
- 不要过度信任预加载脚本 作为进程隔离和明确API边界的替代方案。
运营可见性也很重要。根据 Splunk关于应用安全需求的概述,应用授权应与持续活动监控和日志记录集成，benchmark数据中提到，主动记录和监控授权事件的组织可以在15分钟内检测出95%的未经授权的访问尝试。 。在实践中，这意味着记录被拒绝的操作、令牌刷新失败、角色变化、-consent取消和异常资源访问模式。如果您的发布过程包括混合应用更新，那么在这个生态系统中的一种选择是
__CAPGO_KEEP_0__ ，它为Capgo和Electron应用提供了签名的实时更新。它并没有为您实现授权，但它确实会影响您可以快速发布修复的速度，当授权逻辑、重定向处理或会话__CAPGO_KEEP_1__需要紧急修正时。, which provides signed live updates for Capacitor and Electron apps. That doesn’t implement authorization for you, but it does affect how quickly you can ship fixes when auth logic, redirect handling, or session code needs urgent correction.
良好的应用授权不是一个决定。它是一系列需要彼此支持的决定。您正确地验证用户，请求所需的访问权限，通过安全流程如OAuth 2.0 with PKCE交换令牌，存储机密信息在正确的位置，并在服务器上每次都强制执行权限。
Good app authorization isn’t one decision. It’s a chain of decisions that all need to hold up together. You authenticate the user correctly, request only the access you need, exchange tokens through a safe flow like OAuth 2.0 with PKCE, store secrets in the right place, and enforce permissions on the server every time.
最关键的部分是对 Capacitor 和 Electron 团队来说是边缘的纪律。浏览器时代的快捷方式在接触到本机存储、深度链接、桌面进程边界或应用程序审查要求时不会幸免。通常不做任何特殊事情的团队只是关于范围、会话处理、服务器端检查和审计性的一致。
如果您的当前认证设置感到混乱，那是正常的。从一个边界开始逐步加紧。修复流程。修复存储。将访问规则从 UI 中移出。添加日志以告知您何时有人要求他们不应该有的东西。
这就是如何使应用程序授权变得可管理的。理论上没有变得更简单。 code 中更安全。
Capgo 帮助团队在不等待商店审查的情况下将修复推送到 Capacitor 和 Electron 应用程序，这对于快速修复认证流程、令牌处理或会话错误至关重要。如果您的团队想要对跨平台发布有更紧密的控制、目标发布和回滚支持， Capgo 是值得与您的应用程序授权堆栈一起评估的。
