In Oauth what is the benefit of the access token being opaque

Question

Why was the decision taken that the Client doesn't need to be able to parse the access token?

It seems to me that if the token included, in addition to the current fields, a client_id and a user_id, it would make life much simpler, prevent spoofing, enable authentication, etc.

I've noted that as per section 1.4 of RFC 6749 it does not HAVE to be opaque, but it seems to me that much of OpenID Connect, if not all of it, is a way of making the Access Token into something meaningful. Yes, it adds an ID token, but the fact that it is implemented as something accompanying in stead of embedded in the access token does not change this fact. It seems every video, tutorial and blog post talks about it as if that is to be assumed to be the case (that access tokens will be opaque, because "The client is not the intended audience") ... And yet it is the API or resource provider who cannot establish authentication based on the the bearer having the token.

Actually I need to add that I don't think the token being opaque to the client is the problem. The problem is that the token is a bearer token that doesn't restrict WHO can use it.

Answer 1

In OAuth, or any other protocol where the token can be opaque or transparent, the benefits and risks swing based on what your desired result is:

• If you want the client to be able to parse the access token, you need the token to be transparent.
• If you don't want the client to be able to parse the access token, you need the token to be opaque.

Indeed, this is the definition of opaque and transparent tokens; the client can see into them, or not.

If your token is transparent, you must sign it, otherwise, anyone could simply edit your token contents, and claim anything they want.

So, the first obvious benefit of having an opaque token is that you can just throw away any signing mechanism; you don't need it, and conversely, if you have a proper transparent token, the client can read the token, but not edit it.

Another benefit of having an opaque token is it is more secure; No encryption method is truly random (i.e., there must be a way to decrypt it), meaning you can always tell which encryption protocol is used if you can read enough of the contents of the tokens (transparent tokens). This itself reduces the time to identify your cipher (knowing the protocol). Many people don't think this is very risky, and indeed, if you use more than 80 bits of entropy, they are right (10 truly random characters for your cipher, i.e. "secret key").

However, and this is much more of a risk; transparent tokens allow crackers to play with the contents (because they see them), and some protocols have serious weaknesses that allow you to create collisions or even decode the cipher in a much shorter period because the cracker will know the protocol as well as the contents of valid blocks (most encryption protocols use 16 byte-long blocks, so if your token contains 160 chars of data, you've given the cracker 10 valid combinations to your cipher. This decreases the time it will take for them to identify your cipher by an order of magnitude. Giving them more transparent tokens will further reduce this time as well. Some protocols have a reduced version of this risk, but by the nature of what encoding is, having the encoded block, and decoded block both in your hands, you're always going to make it easier to break.

This is why many choose opaque tokens. Indeed you should always opt for opaque tokens if there is no need for any external entity to be able to parse your token. An example of this is a service framework in which you only pass the token to the service as a blind claim; you have no idea what it says, but you know it works and identifies you. It is only up to the service to confirm it's you via the secret key or cipher.

Opaque tokens also don't require signing, which I mentioned above, they also don't require divulging anything about chosen protocols.

For this reason, they are much more secure, not only mathematically and logically, but get rid of human implementation errors, which is, to be honest, 99% of the reason cracks are ever made in the first place.

Interesting note

Even true randomness means a 36.7% loss (1 divided by e) of combination space when randomly guessing. This means a 1000 possibility combination lock, if guessed randomly, actually has a 1 in 630 chance of getting it correct.

So 1 / e is the absolute best chance you have, and that is pure random.

Any "possibility" that is interesting to a human, "information", is not truly random by definition, and worse, any protocol that is used to decode it, gives up some possible space for the cipher by the way the protocol works. So, in reality, your chances of randomly guessing an answer is significantly smaller than the entropy or combination space most people talk about or think they actually have; it's usually, when all accounts are measured by a good hacker, at least one order of magnitude easier than a layperson thinks.