Hi all, In regards to RSs supporting Bearer and DPoP simultaneously, would it make sense to include some examples of error responses? I'm asking because as an implementor, I had to do a lot of guesswork on how to properly form such responses (and more guesswork means more incompatible implementations, alas). The most puzzling question is, which of the multiple WWW-Authenticate challenges should deliver error information. Some examples:
Example 1 (no access token included): > GET /rs < 401 Unauthorized < WWW-Authenticate: Bearer realm="foo", DPoP realm="foo" According to RFC 6750 Section 3, no error code should be included in this case. This seems clear so far. Example 2 (invalid Bearer token used): > GET /rs > Authorization: Bearer XXX < 401 Unauthorized < WWW-Authenticate: Bearer realm="foo", error="invalid_token", DPoP realm="foo" Question: is it correct that in this case no error code should be included into the DPoP challenge? (vice versa for invalid DPoP token) Example 3 (both Bearer and DPoP tokens used simultaneously): > GET /rs > Authorization: Bearer XXX > Authorization: DPoP XXX < 400 Bad Request < WWW-Authenticate: Bearer realm="foo", error="invalid_request", DPoP realm="foo", error="invalid_request" Question: is it correct that both challenges should include error code? Example 4 (Bearer token included twice, no DPoP token): > POST /rs > Authorization: Bearer XXX > access_token=XXX < 400 Bad Request < WWW-Authenticate: Bearer realm="foo", error="invalid_request", DPoP realm="foo" Question: is it correct that only Bearer challenge should include error code? what if DPoP token was included as well? Example 5 (DPoP bound token used as Bearer - downgrade attack): > GET /rs > Authorization: Bearer XXX < 401 Unauthorized < WWW-Authenticate: Bearer realm="foo", error="invalid_token", DPoP realm="foo" Question: is it correct that Bearer challenge (and not DPoP) should deliver error information? To sum up, my idea is that in cases when we can unambiguously establish the scheme used, we should include error info into the corresponding challenge only. In cases of ambiguity, both challenges should be used to deliver error info. If this make sense, could it be worth covering this topic in the spec? Thanks, Dmitry
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
