React Native 和 React Js 的 JWT Token vs Session Token

Question

我们正在为一个组织构建客户应用程序，其中包含技术堆栈 用于门户的 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 基础或任何身份验证服务

Answer 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);
        }
    }
}