[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