如果你看Authorization Code OAuth type 的流程,是的,有两个精算步骤:
<user_session_id, client_id> => authorization_code
<client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token
在第 1 步中:用户告诉 OAuth 服务器“我想验证此客户端 ( client_id
) 以访问我的资源。这是我的验证 (user_session_id
或其他)”
在第 2 步:客户端 ( client_id
) 告诉 OAuth 服务器“我已获得用户授权 ( authorization_code
),请给我一个访问令牌以供以后访问。这是我的身份验证 ( client_id
& client_secret
)”
你看,如果我们省略第 2 步,则无法保证客户端身份验证。任何客户端都可以使用不同的方法调用 step1client_id
并获得一个访问令牌,client_id
而不是自己的。这就是为什么我们需要第二步。
如果你真的想结合 step1 和 step2,你可以这样做:
<client_id, redirect_uri, client_secret> => access_token, refresh_token
我们在我们的开放 API 平台中使用了这种方法,我们还没有发现任何安全问题。
顺便说一句,实际上有一个隐式授予类型,即:
<client_id, redirect_uri> => access_token, refresh_token
它通常适用于没有服务器后端的仅客户端应用程序。在这种情况下,OAuth 服务器必须确保重定向 URI 属于该客户端(redirect_uri
例如,与 register 相同)。