It is worth mentioning “client collaborative attacks” or “authorization sharing
attacks” because OAuth can make them easier (by packaging authority into an
access token), compared to the alternative of user’s signing-in to an RS
directly. But it is tricky to describe; none of the suggestions are quite
right; and the “right” solution heavily depends on the context.
>> If access tokens are used to identify individuals, and such identifying
>> information (ideally user IDs) is stored with access logs for auditing
>> purposes, then this reduces this attack to an authentication sharing attack.
While this text from Seán may be true, it is bad advice. It implies we should
make access tokens as dangerous as possible (conveying all a person’s
authority) just to discourage sharing.
> Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind
> of attack cannot be countered in the general case.
Even crypto devices aren’t a full solution. Alice can share her authorization
with Bob & Chris by signing-in with their crypto devices.
> an access token … only stating that the holder … is over 21 … should not be
> accepted by the RS
While this may generally be true for an “over 21” claim, it will not always be
true for other claims. In some situations the privacy risk of being personally
identified is far more important than any risk of client collaboration. Staff
accessing a company’s whistle-blower service could be an example: need a
{staff:true} claim to combat spam/gossip; but definitely don’t want to include
a staff id.
A handful of partial strategies appropriate in various circumstances (but all
with downsides) could include:
1. The AS ensures there is only 1 valid access token (or just a few) at any
point in time for a specific claim of a given user.
2. Access token bound to a crypto key locked to one device.
3. Each access token is unique (eg includes a "jti" claim) so an RS can notice
if the same token is presented in different contexts.
4. Access token with "sub" (or provides "sub" via token introspection) to aid
accountability (even if only in a later audit/investigation).
5. Frequent token replacement.
6. Nothing (beyond minimal necessary claims) – to maximize privacy.
What is applicable widely enough to mention in a BCP?
--
James Manger
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
