Tinyauth项目中的跨域Cookie认证问题分析与解决方案

问题背景

在Tinyauth项目的实际部署过程中，开发者可能会遇到一个典型的认证流程问题：用户在Android设备上输入正确的用户名和密码后，系统短暂显示"Welcome Back"提示，随后又跳转回登录页面。而同样的配置在iOS设备上却能正常工作。这种现象通常与浏览器Cookie处理机制和跨域安全策略有关。

技术分析

Cookie的同源策略

现代浏览器基于安全考虑，实施了严格的同源策略(Same-origin policy)。该策略规定：

1. 只有与当前页面同源的网站才能读取和设置Cookie
2. "同源"指的是协议(http/https)、域名和端口号完全相同

在问题描述的配置中：

• 认证服务运行在auth.lan
• 被保护的应用运行在whoami.lan
• 这两个域名虽然同属.lan顶级域，但属于不同的二级域

认证流程解析

当用户访问whoami.lan时，完整的认证流程应该是：

1. 浏览器访问whoami.lan
2. Caddy代理将请求转发给Tinyauth进行认证
3. 认证通过后，Tinyauth尝试设置认证Cookie
4. 由于跨域限制，浏览器拒绝保存这个Cookie
5. 后续请求无法提供有效的认证凭证，导致重新跳转登录

解决方案

正确的域名配置方案

要使Tinyauth的认证机制正常工作，必须确保认证服务和被保护应用位于相同的父域下。推荐采用以下域名结构：

认证服务：auth.mylab.lan
应用服务：whoami.mylab.lan
其他服务：*.mylab.lan

关键配置项

在docker-compose配置中需要特别注意以下参数：

1. APP_URL：必须设置为认证服务的完整URL（如https://auth.mylab.lan）
2. COOKIE_SECURE：确保设置为true以启用安全Cookie
3. 所有服务的Caddy配置中应使用相同的父域

实施步骤

1. 修改DNS配置，将所有服务迁移到同一父域下
2. 更新docker-compose.yml中的域名配置
3. 确保APP_URL环境变量与新的域名结构匹配
4. 重启所有服务使配置生效

经验总结

1. 在规划内部网络服务时，应提前设计好统一的域名结构
2. 认证服务应当作为基础设施的核心组件，与其他服务保持一致的域名层级
3. 跨域问题不仅会影响Tinyauth，也是许多Web应用中常见的配置陷阱
4. 不同浏览器对Cookie策略的实现可能略有差异，这也是问题在iOS和Android上表现不同的原因

通过正确的域名规划和配置，可以确保Tinyauth的认证机制在各种设备和浏览器上都能稳定工作，为内部服务提供可靠的身份验证保障。