OAuth2 Sending Client secret in authorization step

2
votes

I'm building a web app that uses the Oauth2.0 protocol. I have registered my app with the authorization server and received my client id and client secret.

I'm now working on Authorization part and specifically using the Authorization Code grant type. In that process i'm sending the user to the authorize endpoint with the following query parameters:code, client_id, redirect_uri, scope and state. (omitting the client_secret)

The problem that i'm dealing with is i'm getting an error back saying I need to provide the client_secret as well.

I was under the impression the client_secret is not needed at this part and shouldn't be sent in this request but rather when the client sends the authorization code (along with id & secret) to obtain the access token.

So my question is, Is it wrong (against oauth 2 protocol) that the authorization server requires the client secret to be sent in the request for the authorization code?

1
oauth-2.0authorization

1 Answers

1
votes

I am not 100% sure of this, but I did some research myself and what I found is that is not a real problem not to keep the "client secret" a secret. The only possibility of someone malicious being able to get through the Authorization specs is prevented by some facts:

1. Client need to get authorization code directly from the user, not from the service

Even if user indicates the service that he/she trusts the client, the client cannot get authorization code from the service just by showing client id and client secret. Instead, the client has to get the authorization code directly from the user. (This is usually done by URL redirection, which I will talk about later.) So, for the malicious client, it is not enough to know client id/secret trusted by the user. It has to somehow involve or spoof user to give it the authorization code, which should be harder than just knowing client id/secret.

2. Redirect URL is registered with client id/secret

Let’s assume that the malicious client somehow managed to involve the user and make her/him click "Authorize this app" button on the service page. This will trigger the URL redirect response from the service to user’s browser with the authorization code with it. Then the authorization code will be sent from user’s browser to the redirect URL, and the client is supposed to be listening at the redirect URL to receive the authorization code. (The redirect URL can be localhost too, and I figured that this is a typical way that a “public client” receives authorization code.) Since this redirect URL is registered at the service with the client id/secret, the malicious client does not have a way to control where the authorization code is given to. This means the malicious client with your client id/secret has another obstacle to obtain the user’s authorization code.

// copy paste of hideaki answer

Concluding

OAuth2 specify that you need to inform your secret into a request if your application is a server-side based app (different than a single-page application or mobile) which does not make its source code available. However, if you can't control your base code, like in an native mobile application, you should look for another solution.

References

OAuth2 Documentation

Bear similar stack question

Simplifying OAuth2