You asked if you should ask for the client-secret when a client tries to get the resource by an access-token.
###Answer
The answer to your question is NO because the access token represents the authorization result itself and is intended to the pass through the application, the authorization server, and resource server while the client secret should be a secret known only to the application and the authorization server.
I can tell you also that the client secret is equivalent to have an username and password and because of that you should not expose it to the resource server.
Authenticating the request with client secret in order to exchange the temporary authorization code for an access token reduces the risk of an attacker intercepting the authorization code and using it themselves.
An access token itself is a short lived token, that way all sniffable HTTP accesses are made with a token that will expire. Google is using a 5 minute expiration on their OAuth 2 APIs.
Also, in the Authorisation Code Grant flow the access token is never visible to the user, reducing the risk of the token leaking to someone else!
~
###In depth
Lets look at oauth 2 draft :
3.2.1. Client Authentication
Confidential clients or other clients issued client credentials MUST authenticate with the authorization server as described in Section 2.3 when making requests to the token endpoint. Client authentication is used for:
- Enforcing the binding of refresh tokens and authorization codes
to
the client they were issued to. Client authentication is critical
when an authorization code is transmitted to the redirection
endpoint over an insecure channel, or when the redirection URI has
not been registered in full.
- Recovering from a compromised client by disabling the client or
changing its credentials, thus preventing an attacker from abusing
stolen refresh tokens. Changing a single set of client
credentials is significantly faster than revoking an entire set of
refresh tokens.
- Implementing authentication management best practices, which
require periodic credential rotation. Rotation of an entire set
of refresh tokens can be challenging, while rotation of a single
set of client credentials is significantly easier.
A client MAY use the "client_id" request parameter to identify itself when sending requests to the token endpoint.
In the "authorization_code" "grant_type" request to the token endpoint, an unauthenticated client MUST send its "client_id" to prevent itself from inadvertently accepting a code intended for a client with a different "client_id".
This protects the client from substitution of the authentication code. (It provides no additional security for the protected resource.)
And section 2.3 complementing the previous section:
2.3. Client Authentication
If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server.
The authorization server MAY accept any form of client authentication meeting its security requirements.
Confidential clients are typically issued (or establish) a set of client credentials used for authenticating with the authorization server (e.g. password, public/private key pair).
The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
The client MUST NOT use more than one authentication method in each request.
And finally the section 1.4 regarding access tokens:
1.4. Access Token
Access tokens are credentials used to access protected resources.
An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server.
The token may denote an identifier used to retrieve the authorization information, or self-contain the authorization information in a verifiable manner (i.e. a token string consisting of some data and a signature). Additional authentication credentials, which are beyond the scope of this specification, may be required in order for the client to use a token.
The access token provides an abstraction layer, replacing different authorization constructs (e.g. username and password) with a single token understood by the resource server. This abstraction enables issuing access tokens more restrictive than the authorization grant used to obtain them, as well as removing the resource server's need to understand a wide range of authentication methods.
Access tokens can have different formats, structures, and methods of utilization (e.g. cryptographic properties) based on the resource server security requirements. Access token attributes and the methods used to access protected resources are beyond the scope of this specification and are defined by companion specifications.
