Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Oauth2 - long lived Tokens vs Reauthentication in a Client Credentials Flow

We've secured our REST server with OAuth2 and implemented the client credentials grant type for several client apps that we control. Now we're faced with the decision to either make the tokens long lived (i.e. they expire "never") or to have the clients reAuthenticate very often (depending on the refresh token expiration). The first means that a captured token could be used by a malicious party the second means exposing the client secret very often which then in turn can be used to obtain tokens.

Which is more secure in a resource-server to client-server authentication? Both token and client secret can be invalidated if we suspect a theft. Obviously all communication is done via https..

Currently we're thinking the client secret is more powerful than the token and thus a long lived token should be better for this two-legged scenario. (For any three-legged grant type which we'll implement soon we'd prefer a short lived token acting as the user session).

Thanks for your thoughts!

like image 211
Pete Avatar asked Jan 14 '13 09:01

Pete


People also ask

What credentials can the OAuth 2.0 client credentials grant flow use?

The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service.

Why does the client credentials grant type not use refresh tokens?

The token endpoint does not issue a refresh token as refresh tokens are not supported by the client credentials grant. The client credentials grant type is less secure than the authorization code grant type.

What is the difference between auth token and refresh token?

Refresh Token are typically longer lived than Access Tokens and used to request a new Access Token without forcing user authentication. Unlike Access Tokens, Refresh Tokens are only used with the Authorization Server and are never sent to a web service.

Why do we need access token and refresh token?

The idea of refresh tokens is that if an access token is compromised, because it is short-lived, the attacker has a limited window in which to abuse it. Refresh tokens, if compromised, are useless because the attacker requires the client id and secret in addition to the refresh token in order to gain an access token.


1 Answers

According to the specification, the client credentials flow is only allowed for clients that are not running the risk of having its client secret stolen:

The client credentials grant type MUST only be used by confidential clients.

So, if you are using this flow in conjunction with an application on an untrusted platform, you should definitely reconsider this decision.

With the prerequisite that your platform is trusted, there is no need to worry about a stolen client secret. Your decision then comes down weighing up the time an attacker can play with a stolen access token versus the additional overhead for the reauthentication (only one call, but nonetheless a small delay). The reauthentication step itself is a non-issue concerning the exposure of your client secrect, when both participants are trusted and you're using a good transport layer security against MITM attacks.

Also note, that it is not recommended (and also unnecessary) to use refresh tokens with the client credentials flow:

A refresh token SHOULD NOT be included.

like image 185
Jan Gerlinger Avatar answered Oct 19 '22 20:10

Jan Gerlinger