Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Wouldn't it be much simpler and virtually equally secure to replace tokens by pure client credentials?

Client credentials wouldn't expire and resource owners would always be able to modify their access control matrix to revoke any privilege any time.

share|improve this question
My guess is that needing tokens are the result of separating the authorization server from the resource server, but nobody does that. – Lay González Feb 23 '13 at 22:32

In that case -

  1. Client credentials would need to be sent with every request to every server-side app/system that can present resources.
  2. There would be no expiry and no scope limitation on any specific session.
  3. It would be just like legacy basic auth, with all its drawbacks and benefits (simplicity)

In the OAuth client credentials flow, 'client' refers to a client application and not necessarily the resource owner (end user). In some cases, like mobile apps, both are almost the same, as there is usually a single user of the client. Thus, for a simple application, replacing an access token by repeatedly sending client credentials may be a suitable substitute. However, for any distributed application where APIs and resources are distributed across different domains/servers/applications, having a central token endpoint is more scalable and more secure just by virtue of being a single point.

While Facebook has two-legged OAuth for end users (resource owners) using Facebook apps (clients), Facebook provides access tokens to Facebook apps via OAuth client credentials workflow.

share|improve this answer
I kind of agree... except for "There would be no expiry and no scope limitation on any specific session." An access control matrix could be maintained on the resource server so that a resource would be shared to a client only if the resource owner accepts. There would be no expiring, but I don't really get why it should be expiring at all. ¿Could you elaborate more on why tokens are more scalable than client identification via client credentials? – Lay González Feb 24 '13 at 1:21
For example, my facebook password never expires, but I don't feel any risk as long as I'm not making it public. Shouldn't clients be trusted that they will take good care of their credentials or not be trusted even with tokens? – Lay González Feb 24 '13 at 1:25
Based on numerous examples, no, clients should not be trusted to take good care of credentials. It is worth protecting yourself and them from bad credential management. – Rory Alsop Mar 5 '13 at 0:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.