search

oauth-wg / oauth-transaction-tokens

MIT License
7 stars 10 forks source link

Section 2.2.2 - Needs tighter security controls on replacement tokens #74

Closed dhs-aws closed 2 weeks ago

dhs-aws commented 3 months ago

The following text in 2.2.2 is too open ended and should be refactored.

To get a replacement Txn-Token, a service will request a new Txn-Token from the Txn-Token Service and provide the current Txn-Token and other parameters in the request. The Txn-Token service must exercise caution in what kinds of replacement requests it supports so as to not negate the entire value of Txn-Tokens.

First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.

obfuscoder commented 3 months ago

As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.

gffletch commented 2 weeks ago

@dhs-aws please review PR #100 and see if I addressed your comments.

dhs-aws commented 2 weeks ago

Completed. Looks good to me.