I completely agree with Brian’s analysis and suggestions.
FYI, as far as how common this pattern is, “id_token token” with the Form Post
Response Mode is the default for Microsoft Azure Active Directory identity
interactions. You can view Alex Simon’s Identiverse presentations, including
https://www.youtube.com/watch?v=b2_N5Xsm6C8&list=PLpKq7xRiIHaQZzg-a0fFg08yH00zfO9w9&index=3,
to get a sense of how frequently this is used. As he describes between
7:40-9:26 in this presentation, we’re doing approximately 20 billion
authentications per day using OAuth 2.0 with OpenID Connect.
-- Mike
From: Brian Campbell <[email protected]>
Sent: Thursday, January 9, 2020 2:37 PM
To: Richard Backman, Annabelle <[email protected]>
Cc: Mike Jones <[email protected]>; Torsten Lodderstedt
<[email protected]>; oauth <[email protected]>
Subject: Re: [OAUTH-WG] -security-topics-13 and OIDC response types + form_post
response mode
The scenario I described in the beginning of this thread
(response_type=token+id_token and response_mode=form_post) started out a bit
more humbly as a way to facilitate a simple and efficient cross-domain sign-on
with id_token response type and form_post response mode. Somewhat analogous to
SAML SSO using the POST binding. All the transactional data flows through the
browser in the front channel so no additional calls from the client/RP to the
AS/OP are needed. And no short-lived-transactional data has to be shared
amongst AS nodes (or between geographic locations). There are some nice
aspects to front channel flows.
Then along came the desire to have the ability to periodically refresh the user
attributes associated with the session created off of SSO at the client/RP so
as to have fresh data on which to base access control decisions. That was done
by adding an access token into the mix, hence the response_type=token+id_token
with response_mode=form_post, and the RP using it to periodically call the user
info endpoint. Of course this isn't the same as an ID-token-only-front-channel
SSO but it still retains some of the same benefits being a mostly front channel
flow.
I don't know how niche these cases are or even how often they are actually put
into use in actual deployments. But the token+id_token and form_post flow was
fresh in my mind for unrelated reasons when I was re-reviewing the security BCP
draft, which made me think again about the SHOULD NOT wording in Section 3.1.2.
And that led me to this thread and my proposed text that would let the SHOULD
for using sender-constrained access tokens stand on its own and adjust the
qualification on the SHOULD NOT for implicit style access tokens to focus on
the issues that are particular to those flows. This doesn't actually change the
underlying meaning of the draft because sender-constrained access tokens are
still a SHOULD. But I think it would make the draft more cohesive in terms of
where and why certain recommendations are made.
On Thu, Jan 2, 2020 at 2:53 PM Richard Backman, Annabelle
<[email protected]<mailto:[email protected]>> wrote:
Brian and others with similar use cases (Filip?):
The current text does not prohibit your approach, provided you’ve done the due
diligence required by BCP 14 to go against a SHOULD NOT. Could you provide more
detail on the scenarios where you have opted to use these implicit-based
solutions? Is it impractical or infeasible to use an authorization code-based
approach in these scenarios? If this is a particularly niche use case, then it
may not be worth including in the BCP (that’s basically what SHOULD NOT is
for). But if it’s more broadly applicable, then it may be worth tweaking the
“unless…” clause of that paragraph.
–
Annabelle Richard Backman
AWS Identity
From: OAuth <[email protected]<mailto:[email protected]>> on behalf
of Mike Jones
<[email protected]<mailto:[email protected]>>
Date: Saturday, December 28, 2019 at 9:47 AM
To: Brian Campbell
<[email protected]<mailto:[email protected]>>, Torsten
Lodderstedt
<[email protected]<mailto:[email protected]>>
Cc: oauth <[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types
+ form_post response mode
I agree with Brian's suggested text changes.
-- Mike
________________________________
From: Brian Campbell
<[email protected]<mailto:[email protected]>>
Sent: Saturday, December 28, 2019 5:33:24 AM
To: Torsten Lodderstedt
<[email protected]<mailto:[email protected]>>
Cc: Mike Jones
<[email protected]<mailto:[email protected]>>; oauth
<[email protected]<mailto:[email protected]>>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types
+ form_post response mode
The requirement for replay/injection prevention at resource servers is still
there in section 3.2. This change only drops it as a specific qualification on
that SHOULD NOT for flows that send access tokens in the authorization
response. And instead focuses that qualification on the additional risks that
come with sending access tokens in the authorization response. To me, this
feels more consistent.
Looking again at section 3, I'd suggest also moving the fourth paragraph of
section 3.1.2 into section 3.2 so that the description of sender-constrained is
in the subsection that is about sender-constraining.
On Fri, Dec 27, 2019, 5:00 PM Torsten Lodderstedt
<[email protected]<mailto:[email protected]>>
wrote:
Your proposal sounds reasonable on first sight. But thinking again, it would
mean to keep token injection prevention in authorization responses a
requirement while dropping the requirement for replay/injection prevention at
resource servers. To me this feels inconsistent.
Am 28..12.2019 um 00:02 schrieb Brian Campbell
<[email protected]<mailto:[email protected]>>:
I'm not suggesting that it should be a recommended flow. But recommending
against it, as the text does now, seems overreaching and unnecessary. I know
*consensus* was previously found on the text in -13 but best I can recall that
discussion was mostly around Nat advocating to allow room for some future
self-issued IDP type case and the conversation kind of got hung up on that.
Here's some proposed text, which I think still largely captures the intent of
the BCP while not explicitly recommending against legitimate cases like the one
I brought here or Nat's or something like JARM.
In order to avoid these issues, clients SHOULD NOT use the implicit
grant (response type "token") or other response types issuing
access tokens in the authorization response, unless access token injection
in the authorization response is prevented and the aforementioned token
leakage
vectors are mitigated.
The draft already recommends sender-constrained access tokens elsewhere in the
document. It doesn't need to be repeated as a qualifying condition around this
SHOULD NOT.
I am a proponent of PoP/HoK/sender-constrained access tokens (as hopefully is
evident from several attempts at bringing/doing related work here) but I do
worry that the recommendation in the draft is sufficiently unachievable to the
vast majority that it might undermine the credibility of the document. But I
get the aspirational aspect of it and, other than some suggested
tweaks<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FRKujONej-92dT5lr9cLu6hHnw8I&data=02%7C01%7CMichael.Jones%40microsoft.com%7C97c0eb18ae6d4fbd189708d795548ed7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142062719313532&sdata=OvALRfRzfcvIk4NW7lYtnF7mO6ujU3cO1O0OH%2FQVHFc%3D&reserved=0>,
am resigned to see it stay in the document. But let's let that recommendation
stand on its own in the document and not also tie it to other considerations.
On Fri, Dec 27, 2019 at 1:41 PM Torsten Lodderstedt
<[email protected]<mailto:[email protected]>>
wrote:
As Brian said, we have discussed this several times and this text found
consensus.
Using post reduces the attack surface but does not allow to bind the access
token to the legitimate client. We are recommending sender constrained access
tokens in the BCP. So recommending a flow that does not support sender
constrained access tokens is a contradiction.
What do other WG members think?
Am 27.12.2019 um 21:28 schrieb Mike Jones
<[email protected]<mailto:[email protected]>>:
I agree with Brian. Please update the text to describe this already safe usage.
-- Mike
________________________________
From: OAuth <[email protected]<mailto:[email protected]>> on behalf
of Brian Campbell
<[email protected]<mailto:[email protected]>>
Sent: Friday, December 27, 2019 11:03:30 AM
To: oauth <[email protected]<mailto:[email protected]>>
Subject: [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC response types +
form_post response mode
We have a-sometimes used scenario where a client makes an
authorization/authentication request with a "token id_token" response type and
"form_post" response mode (nonce is also sent and exact redirect URI matching
is done at the AS). The access token is never exposed in any URLs and access
token injection is prevented by the at_hash claim in the id token.
That seems to me like a legitimate and reasonable usage scenario. However, it
would fall on the wrong side of the SHOULD NOT in Section 3.1.2 of the Security
BCP-to-be<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3....1..2&data=02%7C01%7CMichael.Jones%40microsoft.com%7C97c0eb18ae6d4fbd189708d795548ed7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142062719313532&sdata=b6mUvX0W0hf6H8ktKdT4vEQlfj7FUjsOIO7IHpCf%2FYs%3D&reserved=0>,
which has:
In order to avoid these issues, clients SHOULD NOT use the implicit
grant (response type "token") or any other response type issuing
access tokens in the authorization response, such as "token id_token"
and "code token id_token", unless the issued access tokens are
sender-constrained and access token injection in the authorization
response is prevented.
I know this particular text has been discussed over and over again so I hate to
revisit it. But based on the aforementioned scenario I think maybe it still
doesn't quite hit the mark. Access token injection is prevented. The token
leakage scenarios mentioned in that section are all avoided. And while I know
sender-constrained is recommended elsewhere in the draft, it's not really a
realistic option for the majority of deployments.
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s).. Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C97c0eb18ae6d4fbd189708d795548ed7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637142062719323523&sdata=JEw5BK%2FMGzVwKeqmofu3SpQ0SLzodsY0W8eKZW9QlX0%3D&reserved=0>
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s).. Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s).. Any review, use,
distribution or disclosure by others is strictly prohibited. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
material for the sole use of the intended recipient(s). Any review, use,
distribution or disclosure by others is strictly prohibited.. If you have
received this communication in error, please notify the sender immediately by
e-mail and delete the message and any file attachments from your computer.
Thank you.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
