Subject: [OAUTH-WG] Request sent to http: instead of https:`

From: Breno <[email-masked]>
Date: Wed, 13 Oct 2010 11:31:28 -0700

Suppose server A documents that their endpoint X is at
https://server.example.com/x; there's no service at the corresponding
http location for security reasons.

Client developer fatfingers URL as http://server.example.com/x

What is the correct response? I understand that this is out of scope
for the spec, but maybe there's agreement on some guidance?

One thing one shouldn't do is serve a 302 here; it would allow
defective clients to remain unpatched.

My preference is to simply return a bare 403 or 404 here -- after all
the endpoint does not exist (404) or if one uses the convention that
resources at http/https are usually identical, then http is a
non-authorized method to access the resource (403).

Thoughts?

-- 
Breno de Medeiros

---

From: Paul Tarjan <[email-masked]>
Date: Wed, 13 Oct 2010 20:46:07 +0000

At Facebook we issue an HTTP 400 with "invalid_request" as the error.

http://graph.facebook.com/me?access_token=blah&client_id=150629244948164

<http://graph.facebook.com/me?access_token=blah&client_id=150629244948164>(the client_id is to enable draft-10 error messaging).

On Oct 13, 2010, at 11:31 AM, Breno wrote:

Thoughts?

--
Breno de Medeiros
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 13 Oct 2010 13:55:23 -0700

On Wed, Oct 13, 2010 at 1:46 PM, Paul Tarjan <[email-masked]> wrote:
> (the client_id is to enable draft-10 error messaging).

Without client_id you get a different error message (JSON as well, but
not OAuth2 compliant). Why do you need this parameter to make the
distinction?

Marius

---

From: Paul Tarjan <[email-masked]>
Date: Wed, 13 Oct 2010 21:00:34 +0000

> not OAuth2 compliant). Why do you need this parameter to make the

Backwards compatibility. When we shipped, OAuth2 was at draft 00 and there was no standard error mechanism. So we invented one that isn't compatible with the current error codes (our key "error" was an array, and the current one is a "string" so we can't just send both).

When the spec finalizes, we'll do a single migration and change the default to be the final format (and all other non-backwards compatible changes).

Paul

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 13 Oct 2010 14:55:43 -0700

> When the spec finalizes, we'll do a single migration and change the default to be the final format (and all other non-backwards compatible changes).

Got it, thanks.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 13 Oct 2010 15:57:47 -0700

Hopefully you also invalidate the token (if bearer) since it was send over an insecure channel.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Breno
> Sent: Wednesday, October 13, 2010 11:31 AM
> To: [email-masked]
> Subject: [OAUTH-WG] Request sent to http: instead of https:`
> 
> https://server.example.com/x; there's no service at the corresponding http
> location for security reasons.
> 
> What is the correct response? I understand that this is out of scope for the
> spec, but maybe there's agreement on some guidance?
> 
> One thing one shouldn't do is serve a 302 here; it would allow defective
> clients to remain unpatched.
> 
> My preference is to simply return a bare 403 or 404 here -- after all the
> endpoint does not exist (404) or if one uses the convention that resources at
> http/https are usually identical, then http is a non-authorized method to
> access the resource (403).
> 
> Thoughts?
> 
> --
> Breno de Medeiros
> [email-masked]

---

From: Jeff Lindsay <[email-masked]>
Date: Wed, 13 Oct 2010 16:12:31 -0700

> Hopefully you also invalidate the token (if bearer) since it was send over

Excuse my naivety, but perhaps that's worth putting in the spec?

---

From: Breno <[email-masked]>
Date: Wed, 13 Oct 2010 16:48:41 -0700

+1 for language in the spec describing how to handle this case

On Wed, Oct 13, 2010 at 4:12 PM, Jeff Lindsay <[email-masked]> wrote:
>> > the

-- 
Breno de Medeiros

---

From: William Mills <[email-masked]>
Date: Wed, 13 Oct 2010 17:04:51 -0700

This rather implies that we're specifying running a full server on port 80 as a "stupid detector".  We should tread carefully here.

> >> Hopefully you also invalidate the token (if bearer) since it was
> send over
> >> an insecure channel.
> >

---

From: Jeff Lindsay <[email-masked]>
Date: Wed, 13 Oct 2010 17:25:18 -0700

>
> This rather implies that we're specifying running a full server on port 80
> as a "stupid detector".  We should tread carefully here.
>

Right, I suppose you're better off not responding on port 80 if possible.
But I imagine this could be phrased in Section 5.0 roughly, "if the resource
server is available over an insecure channel, but does not honor insecure
requests to protected resources, it SHOULD/MUST respond to insecure requests
by invalidating the token and returning an invalid_request error."

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 13 Oct 2010 18:33:19 -0700

I don't think so. If you are not running a server on port 80, the connection will never happen and nothing bad will be send on the wire.

EHL

> Of William Mills
> Sent: Wednesday, October 13, 2010 5:05 PM
> To: Breno; Jeff Lindsay
> Cc: [email-masked]
> Subject: Re: [OAUTH-WG] Request sent to http: instead of https:`
> 
> This rather implies that we're specifying running a full server on port 80 as a
> "stupid detector".  We should tread carefully here.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 13 Oct 2010 18:33:39 -0700

Write it, and I'll get it incorporated.

EHL

> From: Breno [mailto:[email-masked]]
> Sent: Wednesday, October 13, 2010 4:49 PM
> To: Jeff Lindsay
> Cc: Eran Hammer-Lahav; [email-masked]
> >> > From: [email-masked] [mailto:[email-masked]] On
> >> > Behalf Of Breno
> >> > https://server.example.com/x; there's no service at the
> >> > corresponding http location for security reasons.
> >> >
> >> > What is the correct response? I understand that this is out of
> >> > scope for the spec, but maybe there's agreement on some guidance?
> >> >
> >> > My preference is to simply return a bare 403 or 404 here -- after
> >> > all the endpoint does not exist (404) or if one uses the convention
> >> > that resources at http/https are usually identical, then http is a

---

From: Luke Shepard <[email-masked]>
Date: Thu, 14 Oct 2010 02:55:25 +0000

In our architecture, revoking the specific token would mean revoking access to the app, which is something we don't want to do.

We just return an error message but do not invalidate the token. I think that this is fine. Since it doesn't work, it will only be encountered in development.

---

From: Breno <[email-masked]>
Date: Wed, 13 Oct 2010 20:42:52 -0700

Or a connection to evil will happen.

-- 
Breno de Medeiros

---

From: John Panzer <[email-masked]>
Date: Wed, 13 Oct 2010 23:00:50 -0700

In which case, nothing the legit server does can help that client.
Since they're talking to the evil.

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Lukas Rosenstock <[email-masked]>
Date: Thu, 14 Oct 2010 10:21:58 +0200

Facebook doesn't invalidate the token.
Isn't invalidating tokens incompatible with architectures which use
self-contained (cryptographic) tokens instead of random strings?! If
so, making this a requirement would force the server developers to
implement a TRL (token revocation list, similar to a CRL) where every
token - even those cryptographically valid - would need to be checked
against. While this would be great from a security perspective, it
might be impractical.