Styjun

As far as I understand: The client secret was important in OAuth1, but is not that relevant anymore in OAuth2.

But it seems that companies like Google and Twitter require the client-secret to get an access-token.

From the point of view of the authorization-server (for example Google, Twitter, Github...): In which of these situations is the client-secret recommeneded/(required)?

• getting an access-token from the authorization-code.


• getting a new access-token by using the refresh-token.


• getting the resource by the access-token.

Is it enough to require it only to get an access-token by the authorization-code or should it also be commited when someone uses the access-token to get the ressource?

TLDR: In my case: The client-secret is required for the request "get access-token by authorization-code" and for the request "get new access-token & refresh-token by refresh-token". Should I also ask for the client-secret (require it) when a client tries to get the resource by an access-token?

First of all, all the answers to your questions are hidden in RFC-6749 The OAuth 2.0 Authorization Framework.

Your questions:

In which of these situations is the client-secret recommeneded/(required)?
getting an access-token from the authorization-code.

Please refer to section 4.1.3. It tells that client secret is not needed if the client is public, not confidential. Also in section 2.1. Client Types, confidential client types are described as:

Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

Shortly, all clients for Google, Twitter or another big company are confidential. Therefore client id and client secret have to be used when getting access token.

Second question:

getting a new access-token by using the refresh token.

Same answer with the first question. If the client is confidential, client secret is needed.

Third question:

getting the resource by the access token.

Client secret is not needed because the access token is used by the resource server. However, the client secret is used by the authorization server to authenticate the client. If the client has the access token, that means it is already authenticated. Please refer section 7. Accessing Protected Resources.

As a summary, If you have the access token, then you are not needed to require client secret to access a resource. However, If you are a confidential client, then you have to pass the client id and the client secret to the authorization server (Google, Twitter etc.) to get the access token.

No, you should not ask for client secret when client tries to get the resource by an access-token. Access token should be enough, but you need to validate it.

OAuth2, uses the client secret mechanism as a means of authorizing a client, and
the software requesting an access token. You might think of it as a secret password that proves to the authentication server that the client app is authorized to make a request on behalf of the user. (server sided)

So client secret is in a way clients password. In order for a server to use the client it must also send its accompanying password in order to prove it has access to this client. For example: A server sided app requesting an access token has to know the client secret in order to gain the token. This prevents malicious apps that have not been authorized from using the tokens from ever obtaining a valid access token.

Client secrets aren't used in other types of flows, because of the sensitive nature of the client secrets. For example, you wont use them used in JavaScript or desktop applications, both of which can be decompiled, examined, source code viewed, debugged, etc. Servers are should safe and secure for the most part, so the client secret is less vulnerable than it is on a desktop app, etc.

Authorization code flow server sided.

• getting an access-token from the authorization-code.


• getting a new access-token by using the refresh-token.

The way i like to think of it is that if you are logging in a user with a web browser this is client sided application we can trust that the login is the user preforming this action.

If its a server sided language and the communication is preformed on the application server and not the users computer then its server sided you will need to send a client secret in order to validate that this server is in fact the correct server that has access to this client and the call has not been hijacked.

Client secretes are still needed and used with Oauth2 it just depends upon the grant type you are using and if its server sided or client sided application.

From a comment

I don't understand why the client-secret is not needed to get the resource by an access-token

This is actually a separate question and a good one, but i will address it here.

Once an application has an access token it is not validated again. (besides to ensure its from the correct authority probably). Resources assume that if the access token is still valid then i can still use it, so there is no need to validate them again. This is why access tokens are short lived they are normally only valid for one hour. Industry standard accepts that if your access token is stolen that the hacker has access to it for a very limited amount of time so can do little damage.

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.