React Native 和 React Js 的 JWT Token vs Session Token

Posted 2023-02-16

【中文标题】React Native 和 React Js 的 JWT Token vs Session Token

【英文标题】：JWT Token vs Session Token for React Native And react Js

【发布时间】：2022-01-13 23:37:36

【问题描述】：

我们正在为一个组织构建客户应用程序，其中包含技术堆栈 用于门户的 react js 和用于移动设备的 react-native。 在审核期间，建议使用基于 session id 的用户会话，而不是基于 JWT Token。

我们还想使用 OIDC FLow 进行身份验证，使用 OAUTH2.0 进行 API 授权 由于对 JWT 和 Session ID 都有建议，它们各有优缺点。 安全团队坚持使用 Session ID，原因如下

JWT 体积庞大，不可撤销 JWTs are dangerousJWT vsSession 我们应该选择什么安全架构 我们还需要 Session Id 来跟踪吗 用于 OIDC 的 Token 无法发送到 UI，因为它包含隐私和安全信息 我们应该去 JWE 吗？ 我们能否获得与 OIDC 令牌对应的令牌或相关 ID 的哈希值，并在从客户端到后端的每次调用中查找，这样浏览器或客户端应用程序就不需要知道 OIDC 令牌？ 我们真的需要定制的身份验证服务吗？API Gw 本身以及任何 OIDC 是否足以实现端到端安全性，而无需编写 spring 基础或任何身份验证服务

【参考方案1】：

保密

您可以通过几种技术以标准方式满足这些问题，尽管它们需要更复杂的流程：

使用互联网客户端无法读取且不泄露任何敏感信息的不透明令牌 - 请参阅 The Phantom Token Pattern 了解其工作原理。

在浏览器中仅使用可包含不透明令牌的安全 cookie（SameSite=strict、HTTP Only、AES256 加密）。请参阅Token Handler Pattern，其中有一个可以运行的 React SPA 和一个可以插入的 Node 令牌处理程序 API。

通常，这些互联网凭据的行为类似于会话 ID，它们也是不透明的，但您使用的是标准 OAuth，并且您的 API 最终仍通过可数字验证的 JWT 访问令牌进行授权。

令牌处理程序模式

对于 SPA，其想法是启用这样的设置，您可以在其中插入（并可能调整）开源令牌处理程序组件，而不是需要自己开发它们。此模式适用于任何授权服务器：

主要优势如下 - 请参阅 these Curity resources 了解更多详情：

SPA 仅使用最强的 SameSite=strict cookie，浏览器中没有令牌 SPA 可以通过内容交付网络部署到全球多个位置 默认情况下，cookie 仅用于对 API 的 Ajax 请求，这使 SPA 可以更好地控制可用性方面

API 流程

当调用 API 时，流程会像这样工作，并且通常涉及放置在 API 前面的反向代理，以便 API 代码保持简单：

Web 客户端发送一个安全的 cookie，然后 cookie 解密得到不透明的令牌。然后第二个插件从不透明令牌中获取 JWT 并将其转发给 API。

移动客户端向相同的 API 路径发送一个不透明的令牌，在这种情况下，cookie 解密插件什么也不做。然后第二个插件从不透明令牌中获取 JWT 并将其转发给 API。

请注意，如果客户端想要执行优化以检查访问令牌的生命周期，它仍然可以接收expires_in 字段，但我一直建议不要这样做，而是只在客户端中可靠地处理 401，如下所示：

private async fetch(method: string, path: string): Promise<any> 

    try 

        // Try the API call
        return await this.fetchImpl(method, path);

     catch (e) 

        if (!this.isApi401Error(e)) 
            throw ErrorHandler.handleFetchError(e);
        

        await this.oauthClient.refresh();
        try 

            // Retry the API call
            return await this.fetchImpl(method, path);

         catch (e) 

            throw ErrorHandler.handleFetchError(e);
        
    

【讨论】：

感谢您的回复。对于 Apache Webserver 第二个问题，我们是否有类似的问题 - 如果我们有 API Gateway，它是否需要作为 Webserver 的前端，所以在 Webserver 收到任何面向 Internet 的请求然后转到 API Gateway？

令牌处理程序模式的想法是，您可以在任何地方托管静态 Web 内容，这可以使用不同的 API 部署。您可以通过 Apache 提供 Web 内容 - 或者您可以通过第三方内容交付网络提供 Web 内容 - 取决于您的喜好。当然，所有涉及安全数据的 API 请求都需要通过您的 API 网关。

Gary，感谢您的澄清 - Webserver httpd - 托管静态内容 - Webserver - mod_auth_oidc - 如果我们用于 Token Relying，这对 IDP 来说是一个机密客户端，因为存储了 Client Secret - API GW 就在那里接收安全请求，我们通过网络服务器到 API GW 问题是对于任何 API 调用，我们是否必须通过 Mod_Auth_OIDC 本身来，然后点击 API 网关或直接到 APIGW？ - 令牌处理程序模式需要后端组件来拦截从 SPA 或浏览器 [不透明 Cookie] 接收到的令牌并将其转换为 API GW 可理解的令牌 - 我正确吗

Mod_Auth_OIDC 是一个受人尊敬的组件 - 如果您使用它，它将为您完成所有客户端秘密处理和 cookie 内容，以避免您需要编写自己的网站。它可能最适合您的需求。 Token Handler 模式是一种稍微不同的方法，您插入一个 API，然后 SPA 进行自己的重定向，并且可以部署到 CDN。您只会使用其中一个选项，因此请选择您认为最符合您要求的选项。

我在这方面更新了我的原始答案