TLDR;
nonce旨在提供针对授权代码注入攻击的保护，但在公共客户端（例如SPA）的情况下不提供这种保护。
有关nonce参数提供的保护的说明，请查看此处：
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#nonce_as_injection_protection
最后一段回答了您关于nonce专门为公共客户端（例如SPA）提供什么保护的问题：
需要注意的是，nonce不保护公共客户端的授权码，因为攻击者不需要执行授权码注入攻击。相反，攻击者可以使用窃取的授权代码直接调用令牌端点。
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.5.3.2-4
下一节将讨论下一个问题，即“如果nonce参数不为公共客户端提供保护，那么我应该使用什么？“
PKCE是OAuth客户端最明显的解决方案，因为它现在可用（最初用于OAuth原生应用程序），而nonce适用于OpenID Connect客户端。
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.5.3.3-2
现在，如果你问PKCE和nonce之间的区别是什么，为什么PKCE可以保护公共客户端，而nonce不能，区别在于OAuth/OIDC流程的不同步骤。
随机数由客户端生成，并与授权请求一起发送，类似于PKCE中的code_challenge和code_challenge_method（可选）。OP存储值并返回authorization code。然而，接下来的情况有所不同。
使用nonce：

• 客户端将authorization code发送到OP。
• OP将授权请求中收到的nonce放入（ID）令牌中，并返回令牌
  *客户端将令牌中的nonce值与会话存储中的值进行核对

使用PKCE：

• 客户端将authorization code和code_verifier结束到OP
  *OP检查code_verifier，将其与code_challenge_method进行转换，并检查其是否与之前接收的code_challenge匹配。
• OP返回令牌。

我加粗了每一个“保护发生”的步骤。使用nonce，客户端的负担更重，需要验证令牌中的nonce值是否与之前创建和存储的值匹配。使用PKCE，OP执行code_verifier转换，并将其与早期的code_challenge进行比较。
如果恶意客户端能够窃取授权代码，则无法防止该客户端获取令牌并使用它。它不必检查nonce参数。它不在乎。但是，使用PKCE，恶意客户端需要拥有code_verifier，否则OP将不会返回令牌。