Hi Mike,
The Form Post Response Mode keeps the access_token out of the URL, but
it doesn't prevent the token from traversing through the browser. So a
man-in-the-browser attack may be able to intercept the values. It should
help with leakage in logs.
Thanks,
George
On 11/20/18 4:00 PM, Mike Jones wrote:
Next question – doesn’t using the Form Post Response Mode
https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
mitigate the threats you’re describing below John? If so, I believe
the Security Topics draft should say this.
I believe we owe it to readers to present the complete picture, which
is why I believe that describing profiles using ID Tokens and the Form
Post Response Mode are in scope.
-- Mike
*From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of * John Bradley
*Sent:* Tuesday, November 20, 2018 7:47 AM
*To:* oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend
authorization code instead of implicit
Yes the at_hash protects the client from accepting an injected AT.
Unfortunately it doesn't do anything to protect against leakage in
logs or redirects.
So without the AT using some sort of POP mechanism it is hard to say
sending it in a redirect is a good security practice.
John B.
On 11/20/2018 4:35 AM, Torsten Lodderstedt wrote:
Hi Mike,
I agree that OIDC hybrid flows offer additional security over the OAuth
implicit grant and are used in the wild. On my slides and in the initial
version of the new section, we had included the hybrid OIDC flows because of
their known token injection countermeasures.
I nevertheless feel very uncomfortable to recommend those flows and any
flow issuing access tokens in the front channel. In the course of the detailed
review of the new text we realized two issues:
1) Since the access token is exposed in the URL, such flows possess a
significantly higher risk to leak the access token (e.g. through browser
history, open redirection and even referrer headers) than the code grant.
2) There is no viable way to sender constrain access tokens issued in the
front channel. Given the WG decided to recommend use of sender constraint
tokens
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2),
it seems contradictory to recommend response types not supporting such an
approach.
kind regards,
Torsten.
Am 19.11.2018 um 23:13 schrieb Mike
Jones<Michael.Jones=40microsoft....@dmarc.ietf.org>
<mailto:Michael.Jones=40microsoft....@dmarc.ietf.org>:
This description of the situation is an oversimplification. OpenID
Connect secures the implicit flow against token injection attacks by including
the at_hash (access token hash) in the ID Token, enabling the client to
validate that the access token was created by the issuer in the ID Token (which
is also the OAuth Issuer, as described in RFC 8414). (Note that this
mitigation was described in draft-ietf-oauth-mix-up-mitigation.)
Given the prevalence of this known-good solution for securing the
implicit flow, I would request that the draft be updated to describe this
mitigation. At the same time, I’m fine with the draft recommending the code
flow over the implicit flow when this mitigation is not used.
Thank
you,
-- Mike
From: OAuth<oauth-boun...@ietf.org> <mailto:oauth-boun...@ietf.org> On
Behalf Of Hannes Tschofenig
Sent: Monday, November 19, 2018 2:34 AM
To: oauth<oauth@ietf.org> <mailto:oauth@ietf.org>
Subject: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
code instead of implicit
Hi all,
The authors of the OAuth Security Topics draft came to the conclusion
that it is not possible to adequately secure the implicit flow against token
injection since potential solutions like token binding or JARM are in an early
stage of adoption. For this reason, and since CORS allows browser-based apps to
send requests to the token endpoint, Torsten suggested to use the authorization
code instead of the implicit grant in call cases in his presentation
(seehttps://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
A hum in the room at IETF#103 concluded strong support for his
recommendations. We would like to confirm the discussion on the list.
Please provide a response by December 3rd.
Ciao
Hannes & Rifaat
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
