问题
I have been trying to understand how OAuth2 works. At first I thought it was redundant to spend one extra step exchanging auth code + client secret for access token - why not have server return access token directly. For that I found this explanation.
Then what confuses me is, why does it need a clientId and a client secret, instead of just a secret? A secret which can both declare and prove itself. The client app then can simply pass it to server when it sends user there to authorize itself for accessing server resource.
Thanks!
回答1:
Imagine the client signs the request with the secret and sends just the signature. How does the server know which secret to use? Presumably the server supports multiple consumers.
回答2:
The client id is sent in the first part of the token dance to identify the client. This id is sent in an insecure way, in the URL. Even on the authz server end of this request the id may be exposed in an insecure way where the authz server redirects the user agent to the authorization page. So the client id is not meant to be secure, just to identify the client.
Only after receiving the authorization code (after user authorization), does the client then need to obtain the access token in a more secured way. This is where the client secret is used over TLS.
回答3:
You can have the server return the access token directly. You need to request Implicit grant (response_type with the value token instead of code).
The authorization server returns the access token directly.
This type of grant is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret or client id because all of the application code and storage is easily accessible. If your client can keep a secret, it is recommended that you use a more secure grant type.
来源：https://stackoverflow.com/questions/33557204/why-do-we-need-both-client-id-and-client-secret-instead-of-just-clientsecret