+1 to this.
I think we also need to keep in mind that it's incredibly common for an
OAuth client to talk to multiple resource servers with a single token
from a single authorization server that's been configured (and agreed
upon, out of band) to protect those resource servers. The client doesn't
know or care about the details of the deployment, it just knows that it
can get a token to work across various parts of the API.
-- Justin
On 9/30/2016 4:03 PM, Brian Campbell wrote:
Sending this to both the Tokbind and OAuth lists.
There is text now in HTTPSTB that says that a TB ID must only be
conveyed to a different server, if the associated server explicitly
singles to do so. Specifically these two snippets,
https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5
<https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-5> has
However, such applications MUST only convey Token Binding IDs to
other servers if the server associated with a Token Binding ID
explicitly signals to do so, e.g., by returning an Include-Referred-
Token-Binding-ID HTTP response header field.
and
https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3
<https://tools.ietf.org/html/draft-ietf-tokbind-https-06#section-7.3> has
Also, applications must take care to only reveal Token Binding IDs to
other endpoints if the server associated with a Token Binding ID
explicitly signals to do so, see Section 5
"Implementation Considerations".
This seems like it might be problematic for token binding of OAuth
access tokens. Many/most OAuth flows don't begin at the resource sever
(token consumer) but at the authorization server (token provider) so
there's not an opportunity for such an explicit signal. And even when
a request is made to the resource sever (token consumer) without a
token or with a bad token, there isn't a redirect but rather a 40x is
returned (see https://tools.ietf.org/html/rfc6750#section-3
<https://tools.ietf.org/html/rfc6750#section-3>).
The relationship between OAuth servers is much more of an implicit
thing in how the OAuth client application (different than a browser
client) interacts with those severs. And there's correlatable info
already flowing between the two so revealing a referred TB doesn't
make the privacy situation any different. But it can greatly improve
the security of the access tokens.
Can the text in HTTPSTB be reworked slightly to allow for an implicit
okay or a prearrangement to reveal referred Token Binding IDs for
applications which are not web browsers? Otherwise OAuth clients will
have to ignore that MUST or a token (pun intended) but really
meaningless signal will have to be invented for OAuth (like maybe a
new auth-param with the WWW-Authenticate Response Header Field from
RFC 6750.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
