[Openid-specs-ab] Whether to allow http redirection URIs for confidential clients
Torsten Lodderstedt
torsten at lodderstedt.net
Sun Oct 27 16:29:58 UTC 2013
Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> schrieb:
>Here is the sentence you refer to:
>
>"Therefore, if the client relies on the authorization code for its own
>resource owner authentication, the client redirection endpoint MUST
>require the use of TLS."
>
>That note was meant for general OAuth 2.0. With OIDC we have the signed
>ID token, so clients will be using that instead to authenticate the
>resource owner.
The ID token won't prevent an attacker to steal a code on the wire and use it to login with the victim's identity at the legitimate website (client). The Id token prevents a rough client from impersonating a user.
>
>I read the entire section carefully, and it's fully in line with
>section
>3.1.2.1 that I quoted in my previous email, as well as with what
>Connect
>has now specified. I.e. there is a strong recommendation to use TLS,
>but
>there's also the understanding that TLS wouldn't be practical for a
>number of clients and that's taken into account too.
>
>
>Vladimir
>
>
>On Fri, 2013-10-25 at 07:41 +0200, Torsten Lodderstedt wrote:
>> What about
>>
>> http://tools.ietf.org/html/rfc6749#section-10.5
>>
>> second paragraph, last sentence?
>>
>> We explicitly added this statement/requirement in order to address
>the
>> specific risk associated with code theft when OAuth is used for
>> authentication.
>>
>>
>>
>> Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com> schrieb:
>> Hi John, hi guys,
>>
>> It looks like my previous email didn't get through.
>>
>> The current OIDC spec doesn't actually relax the TLS
>requirement in
>> regard to the redirection endpoint:
>>
>> http://tools.ietf.org/html/rfc6749#section-3.1.2.1
>>
>> 3.1.2.1. [Redirection] Endpoint Request Confidentiality
>>
>> The redirection endpoint SHOULD require the use of TLS as
>described
>> in Section 1.6 when the requested response type is "code" or
>"token",
>> or when the redirection request will result in the
>transmission of
>> sensitive credentials over an open network. This
>specification does
>> not mandate the use of TLS because at the time of this
>writing,
>> requiring clients to deploy TLS is a significant hurdle for
>many
>> client developers. If TLS is not available, the
>authorization server
>> SHOULD warn the resource owner
>> about the insecure endpoint prior to
>> redirection (e.g., display a message during the authorization
>> request).
>>
>> So we're actually fine with that.
>>
>>
>> This is the OIDC core redirect_uri spec for the "code" flow:
>>
>>
>http://openid.bitbucket.org/openid-connect-core-1_0.html#AuthorizationRequest
>>
>> redirect_uri
>> REQUIRED. .... When using this flow, the Redirection URI MAY
>use the
>> http scheme, provided that the Client Type is confidential,
>as defined
>> in Section 2.1 of OAuth 2.0; otherwise, it MUST use the https
>scheme.
>> state
>>
>>
>> And here for the "implicit" flow:
>>
>>
>http://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest
>>
>> redirect_uri
>> REQUIRED. ... When using this flow,
>> the Redirection URI MUST NOT use
>> the http scheme unless the Client is a native application, in
>which case
>> it MAY use the http: scheme with localhost as the hostname.
>>
>>
>> --
>> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir at nimbusds.com
>>
>>
>>
>> -------- Original Message --------
>> Subject: Re: Whether to allow http redirection URIs for
>confidential
>> clients
>> From: John Bradley <ve7jtb at ve7jtb.com>
>> Date: Thu, October 24, 2013 7:54 pm
>> To: Mike Jones <Michael.Jones at microsoft.com>
>> Cc: Vladimir Dzhuvinov / NimbusDS <vladimir at nimbusds.com>,
>> "openid-specs-ab at lists.openid.net"
><openid-specs-ab at lists.openid.net>
>>
>> Sorry yes it went back and forth.
>>
>> The question is if we should override the OAuth RFC's
>requirement for
>> TLS on the client in favour of allowing adoption of connect
>by those web
>> sites that don't implement TLS for login
>> and session cookies.
>>
>>
>> If a site has no TLS and can have it's cookies and passwords
>leaked,
>> then Connect without TLS is arguably no worse than the
>current situation
>> and arguably better because at-least the user is not leaking
>the
>> password.
>>
>>
>> So do we allow the bad thing to prevent the worse thing?
>>
>>
>> This makes code more likely to leak, and there is no real
>protection
>> possible other than using a hmac of the device fingerprint as
>the nonce,
>> but a TLS cert for the client is much simpler.
>>
>>
>> John B.
>>
>> On 2013-10-24, at 11:37 AM, Mike Jones
><Michael.Jones at microsoft.com>
>> wrote:
>>
>> John, you wrote: “At the IIW F2F we took a decision that we
>should
>> match the RFC and require the client to have a TLS endpoint
>if using a
>> http redirect.(not a custom scheme)”. While the working
>group was
>> leaning that way early in the discussion, Naveen and others
>pushed back,
>> and that doesn’t actually match the decision that we recorded
>in the
>> notes, which say:
>> OP may prevent registration of redirect_uris that do not use
>> https
>> A confidential client needs to be required to use http
>> We will discuss this further on the list
>>
>> Consider this the start of the further discussion on the
>list. What do
>> people think?
>>
>> -- Mike
>>
>> From: openid-specs-ab-bounces at lists.openid.net
>> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf
>Of John
>> Bradley
>> Sent: Thursday, October 24, 2013 5:42 AM
>> To: Vladimir Dzhuvinov / NimbusDS
>> Cc: openid-specs-ab at lists.openid.net
>> Subject: Re: [Openid-specs-ab] First Release Candidates for
>final OpenID
>> Connect specifications
>>
>>
>>
>> Snip
>> On 2013-10-24, at 1:36 AM, "Vladimir Dzhuvinov / NimbusDS"
>> <vladimir at nimbusds.com> wrote:
>>
>>
>>
>>
>>
>>
>> "When using this flow, the redirection URI
>> MAY use the http scheme,
>> provided that the Client Type is confidential, as defined in
>Section 2.1
>> of OAuth 2.0; otherwise, it MUST use the https scheme" -
>This,
>> surprisingly enough, is relaxed in comparison
>> tohttp://tools.ietf.org/html/rfc6749#section-10.5.
>>
>> RFC 6749 states: "Authorization codes operate as plaintext
>bearer
>> credentials, used to verify that the resource owner who
>granted
>> authorization at the authorization server is the same
>resource owner
>> returning to the client to complete the process. Therefore,
>if the
>> client relies on the authorization code for its own resource
>owner
>> authentication, the client redirection endpoint MUST require
>the use of
>> TLS."
>>
>> Why is Connect, in this particular case, less restrictive
>than OAuth?
>>
>>
>>
>> John, can you speak to why we’re allowing http redirect_uri
>values
>> when apparently OAuth
>> doesn’t?
>>
>> I had some questions on this point as well. I believe the
>thinking is
>> that since the client is protecting the secret and the code
>is sent to
>> the /token endpoint with client authentication, even if
>someone was able
>> to hijack the code value they couldn't exchange it for the
>access (and
>> possibly refresh) tokens. If we are trying to make things
>simpler, then
>> just moving all of it to TLS makes sense. To me, the only
>exception is
>> localhost.
>>
>> The attacker could inject the authorization code into the
>same
>> application as used by the victim in order to impersonate
>her/him.
>>
>>
>> For this to happen the attacker should also have gained
>control over the
>> RP (the application), i.e. have the RPs' authentication
>credentials.
>>
>>
>>
>>
>>
>>
>> Early OAuth 2 inherited the idea from OAuth 1 that the client
>didn't
>> need to have a TLS cert. We were matching that. At the IIW
>F2F we took
>> a
>> decision that we should match the RFC and require the client
>to have a
>> TLS endpoint if using a http redirect.(not a custom scheme)
>>
>>
>>
>> Earlier in this thread there is also a question about exact
>redirect_uri
>> matching and if it is required for confidential clients. In
>the code
>> flow if the token is leaked through an open redirector then
>it can be
>> presented to the real client and the attacker gets in as the
>user.
>>
>>
>>
>> The OAuth AS side mitigation of this is the confidential
>client passing
>> the redirect URI to the AS in the token request and the AS
>performing an
>> exact match on the redirect URI, and failing if it is
>different. In
>> the wild it appears AS are also not being sufficiently strict
> on
>> matching that and causing some problems in deployments.
>>
>>
>>
>> The client side mitigation for this is using nonce in the
>signed token
>> to allow the client to check on its own if it initiated the
>> request
>> through the same browser that presented the code. However
>that was left
>> as optional for code.
>>
>>
>>
>> At the end of the day the reality is that some of the large
>IdP only
>> allow exact matching of redirect_uri. If some are strict
>and some
>> allow query parameters then clients using query parameters to
>carry
>> state will fail and not be interoperable.
>>
>>
>>
>> The WG decided that the strict matching of the redirect_uri
>by those IDP
>> is allowed by the RFC, rather than forcing them to change
>and do
>> pattern matching for interoperability we precluded clients
>from hiding
>> state in the query parameters and forced them to use the
>"state"
>> parameter.
>>
>>
>>
>> So yes for a fully RFC compliant OAuth server with a client
>that is
>> truly confidential and not just pretending, it would be
>secure for the
>> AS to relax the matching for the redirect_uri in the request
>to the
>> authorization server as
>> long as it records that URI and is doing an
>> exact string match on it aginst the one sent to the token
>endpoint. It
>> is not however safe for a client to assume all AS are going
>to act that
>> way. The only safe thing for the client is to assume exact
>string
>> match.
>>
>>
>>
>> So while this relates to security issues the final decision
>was taken
>> for interoperability of the client.
>>
>>
>>
>> John B.
>>
>>
>______________________________________________________________
>>
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
More information about the Openid-specs-ab
mailing list