无需修改下游应用，通过Okta认证访问CloudFront关联S3资源的方案咨询

基于你的约束（不能修改下游应用、避开LambdaEdge大小限制、使用Okta OIDC认证），以下是适配现有架构的落地方案：

核心架构逻辑 #

通过CloudFront Functions替代LambdaEdge做轻量认证拦截，结合Angular着陆页集成Okta OIDC完成登录，利用Cookie传递认证令牌，实现对/secured路径的透明认证，/unsecured路径直接放行。

具体实现步骤 #

1. 改造Angular着陆页集成Okta OIDC #

• 集成Okta官方OIDC SDK到Angular应用，实现完整的登录流程
• 登录成功后，将Okta返回的ID Token存入HttpOnly、Secure、SameSite=Strict的Cookie（Cookie名称比如Okta-ID-Token），确保CloudFront能读取该Cookie
• 配置Okta回调URL为你的CloudFront自定义域名（比如https://your-domain.com/okta-callback），回调时从Okta的state参数中提取用户原请求的资源路径，完成登录后自动跳转到该路径
• 在Angular应用中添加登录入口，处理未认证用户的跳转逻辑

2. 调整CloudFront分发配置 #

• 新增两个路径行为：
  • /secured/*行为：关联CloudFront Functions，启用自定义错误响应
  • /unsecured/*行为：设置为直接放行，无需认证，保持现有S3源站配置
• 配置自定义错误响应：当CloudFront返回401 Unauthorized时，重定向到Angular登录页，同时传递原请求URL作为参数（比如https://your-domain.com/login?redirect=${request.uri}）
• 确保CloudFront分发启用了Cookie转发，允许读取Okta-ID-Token Cookie

3. 编写CloudFront Functions认证逻辑 #

创建CloudFront Functions（替代LambdaEdge，无部署包大小限制），实现以下逻辑：

function handler(event) {
    const request = event.request;
    const uri = request.uri;
    
    // 放行unsecured路径
    if (uri.startsWith('/unsecured/')) {
        return request;
    }
    
    // 处理secured路径的认证
    if (uri.startsWith('/secured/')) {
        const cookies = request.headers.cookie ? request.headers.cookie.value.split('; ') : [];
        const idTokenCookie = cookies.find(c => c.startsWith('Okta-ID-Token='));
        
        if (!idTokenCookie) {
            // 无令牌，返回401触发重定向
            return {
                statusCode: 401,
                statusDescription: 'Unauthorized'
            };
        }
        
        const idToken = idTokenCookie.split('=')[1];
        // 验证Token：替换为你的Okta公钥、受众、发行方配置
        const isValid = verifyOktaToken(idToken, 'YOUR_OKTA_PUBLIC_KEY', 'YOUR_OKTA_AUDIENCE', 'YOUR_OKTA_ISSUER');
        
        if (!isValid) {
            return {
                statusCode: 401,
                statusDescription: 'Unauthorized'
            };
        }
        
        // 认证通过，放行请求到S3
        return request;
    }
    
    // 其他路径默认放行（比如Angular着陆页）
    return request;
}

// Token验证函数（简化版，实际需实现JWT签名验证和字段校验）
function verifyOktaToken(token, publicKey, audience, issuer) {
    // 解析JWT头部和负载，验证签名、过期时间、aud、iss等字段
    // 可提前将Okta的公钥硬编码到函数中（从Okta JWKS获取）
    // 示例逻辑，需根据实际情况完善
    try {
        // 实现JWT验证逻辑
        return true;
    } catch (e) {
        return false;
    }
}

• 注意：CloudFront Functions无法调用外部API，需提前从Okta的JWKS端点提取公钥，硬编码到函数中，定期更新公钥即可

4. 配置S3桶权限 #

• Secured桶：仅允许CloudFront OAI（Origin Access Identity）访问，禁止公网直接访问，确保只有通过CloudFront认证的请求才能获取资源
• Unsecured桶：保持现有配置，允许CloudFront OAI访问或公网可读

5. 下游应用路由配置 #

确保下游应用的所有资源请求都指向CloudFront自定义域名，而非直接访问S3，Route53现有配置保持不变即可

关键注意事项 #

• Cookie安全性：必须设置Cookie为HttpOnly、Secure、SameSite=Strict，防止XSS和CSRF攻击
• Token缓存：对于/secured路径，建议设置缓存策略为不缓存，或根据Token中的用户ID生成缓存键，避免不同用户的资源混淆
• 公钥更新：定期从Okta JWKS端点更新公钥，确保Token验证的有效性

内容的提问来源于stack exchange，提问作者nikita kakraniya