Bearer tokens should not be supported or be deprecated

[Denisthemalice]

Bearer tokens are so easy to be forwarded by a client to another client that they should not be supported.

This does not mean that one client cannot forward sender-constrained tokens to another client, but this is less straightforward.

[jricher]

The attacks on bearer tokens don't involve a client knowingly forwarding the token, but rather another party such as the rs using or forwarding the token. A client can always simply forward the key material, or even make a call on behalf of someone else. Nothing can stop that.

This was discussed extensively when the group was founded. There is strong desire to keep support for bearer tokens but GNAP has made them non-default and requires them to be flagged specially.

[aaronpk]

Agreed, a client can voluntarily share key material and tokens or even raw data, and there's no way to stop that. Like Justin said, the interesting things that can be prevented by avoiding bearer tokens are parties other than the client (e.g. a Resource Server) passing on the token accidentally or maliciously. That said, there are still cases where this is not a concern, such as when all roles (client, RS, AS) are controlled by a single entity, in which case the simplicity of bearer tokens may be appealing.

[Denisthemalice]

@jricher wrote:

"The attacks on bearer tokens don't involve a client knowingly forwarding the token, but rather another party such as the rs using or forwarding the token."

This forwarding attack by a RS can easily be countered. It is sufficient to include into the access token either a true identifier or a concealed identifier of the RS, so that each RS can verify to which RS the access token was intended to.

This has been explained on the mailing list about one year ago.

This is an additional argument why the structure of the access token should be defined in the core document.

@jricher also wrote:

A client can always simply forward the key material, or even make a call on behalf of someone else. Nothing can stop that.

Indeed, it is possible that a user forwards the key material to another, but the attack is less easy for the second user if the token is a sender-constrained token. However, the sentence "Nothing can stop that" is inappropriate. Collusion attacks between two users cannot be prevented but can be detected . If the RS is capable to perform that detection, then the attack can be defeated (and thus "stopped").

If a client simply makes a call on behalf of someone else, it will be get attributes and/or rights associated with that someone else. It may impersonate that someone else but this does not mean that the attributes and rights from someone can be mixed with the attributes and rights from that someone else.

Details on how to defeat user collaborative attacks and their implications are discussed in issue #290.

[aaronpk]

@Denisthemalice please respond to my comment on #290 before continuing to repeat arguments in other issues

[Denisthemalice]

I have just replied to your comment on #290

[aaronpk]

Bearer tokens are not recommended according to the security considerations in 12.6

[yaronf]

We rightly avoid normative language in the Security Considerations. But should we add to the description of the bearer flag in 3.2.1,

As per the Security Considerations (ref to 12.6), bearer tokens are NOT RECOMMENDED.

[fimbault]

We might, although I think it's too strong. Bearer tokens might be reasonable in a number of cases.