在oauth中，您使用客户端ID /密码进行请求以获取授权码。然后，您再次发出请求，以将授权代码交换为访问令牌。我的问题是：
为什么需要两步过程而不是首先获得访问令牌？如何使整个过程更安全？还是还有其他原因。
我说的是服务器端应用程序（例如php），它从远程服务器而不是javascript请求授权。
答案 0 :(得分：2)
可以通过一个请求来完成它-然后称为隐式流。将response_type设置为token或id_token token的单个请求。
使用访问代码（授权流程）而不是直接返回令牌的一般想法是对最终用户隐藏令牌。第二个请求通常由后端服务器而不是浏览器完成。
您可以在此处找到更多详细信息：https://auth0.com/docs/api-auth/which-oauth-flow-to-use
答案 1 :(得分：0)
在oauth中，您使用客户端ID /秘密请求获取授权码。
授权代码请求不包含客户端密码。它仅包含客户端ID和重定向URL，这使授权服务器可以验证来自已知客户端的请求。
要首先获得访问令牌，这需要执行两步过程吗？如何使整个过程更安全？还是还有其他原因。
如果我们忘记了隐式流程，其中涉及从第一次调用中检索访问令牌，我会说这是为了提高安全性。
使用授权码流时，可以使用用户代理（浏览器）来启动流。这意味着，用户代理会将最终用户重定向到授权服务器以进行身份验证（获取和验证最终用户的用户名密码）。如果最终用户验证成功，授权服务器将发送授权代码。这是一个临时机密，绑定到原始授权码请求。
现在，客户端使用授权代码并直接联系授权服务器以获取访问（和其他）令牌。第二步发生在用户代理之外。
如果客户端是机密客户端，具有客户端ID以及客户端机密的客户端，则第二个调用将要求生成此客户端机密。因此，它在内部包含一个客户端验证过程。从授权服务器的角度来看，如果客户端身份验证失败，令牌请求将被拒绝。这为授权代码窃取提供了保护。
第二步，我们避免访问令牌暴露给第三方。例如，在隐式流中，访问令牌作为URL片段通过用户代理发送。如果用户代理受到威胁（例如：-由某些恶意代码操纵），则可以提取此访问令牌。
那公共客户呢？这意味着由于其性质而无法获得客户机密的客户（例如：-无法通过存储来保护机密的客户）
公共客户端使用PKCE。必须使用它来避免授权代码被盗用。因此，在令牌请求（第二次调用）中，客户端将直接发送代码验证程序。由于对用户代理进行了哈希处理（代码质询），因此用户代理无法在第一个请求中获得代码验证者。因此，令牌请求现在包含一个只有客户端和授权服务器才知道的秘密。
如果同时比较两种情况（公共客户端和机密客户端），则可以看到第二个呼叫如何增加额外的安全性。
答案 2 :(得分：0)
更安全...或更安全？取决于其应用方式。
看看： https://auth0.com/docs/api-auth/which-oauth-flow-to-use
您会注意到，在服务器端使用auth代码流时会使用它。还要注意，当请求验证码时，响应URL带有带问号的查询字符串：https://example-app.com/redirect?code=g0ZGZmNjVmOWI&state=dkZmYxMzE2
使用水疗中心时，您将使用隐式流程。请注意，访问令牌是通过网址https://example-app.com/redirect#access_token=MyMzFjNTk2NTk4ZTYyZGI3
中的anchor（＃）发送的锚定值将永远不会发送到服务器。仅限水疗中心的客户使用。服务器将永远无法看到访问令牌。
服务器应用程序获得重定向后，它必须能够读取它。可以，因为url带有问号而不是＃。如果可以直接发送令牌，则客户端可以在浏览器历史记录中或通过提琴手看到访问令牌。