Subject: [OAUTH-WG] Separate HTTP and HTTPS tokens

From: "Manger, James H" <[email-masked]>
Date: Fri, 14 May 2010 13:25:20 +1000

Some APIs (and certainly lots of web sites) use a mix of HTTPS and HTTP resources. Using the same bearer token for both sets of resources limits security of the HTTPS interactions to the insecurity of the HTTP ones.
A better approach is to use separate tokens. Exposure of a token used on HTTP does not compromise the interactions on HTTPS.

There is lots of existing practise with this approach: issuing 2 cookies when a user logs in: one marked "secure" and the other not. HTTP and HTTPS interactions can all be tied to the same user, but the HTTP ones don't reduce the security of the HTTPS ones.

Suggested solution in OAuth: return multiple tokens in a token response.

Change the token response format to an array of blobs with token info.

[
   { "access_token":"SlAV32hkKG", "sites":["http://api.example.org"] },
   { "access_token":"Id87d6dDd", "sites":["https://api.example.org"] }
]

For the common case of only needing 1 token the added complexity is trivial:
* at the server: bracket the JSON value with "[" and "]";
* at the client: pick JSON.parse(s)[0].

It does add some complexity to generic clients, and libraries.

This mechanism allows tokens with and without secrets to be delivered in one request.

This mechanism is also useful when least-privilege tokens are wanted. For instance, one authorization flow can deliver different tokens with different scopes/permissions so only the minimum authority is exposed in specific API calls.

This mechanism might also be useful when supporting different authentication algorithms (eg bearer token, HMAC-SHA1, CMAC-AES128...). Using the same secret with drastically different crypto algs is generally bad form. Separate tokens for each mechanism can be returned.

This mechanism might be helpful for services with disparate collections of resource servers. A compromise at one host doesn't affect another if different tokens were issued for each.

There have been other suggestions of repeated call to the token endpoint to upgrade/downgrade tokens. This mechanism doesn't preclude repeated calls, but it can avoid them in some circumstances.

Any support?
(If you don't like it, is it because you don't think there are enough cases where HTTP & HTTPS are mixed? Or is it the syntax?)

-- 
James Manger

---

From: David Recordon <[email-masked]>
Date: Thu, 13 May 2010 21:15:57 -0700

Why would we support bearer tokens over HTTP? Is someone planning to
implement this?

On Thu, May 13, 2010 at 8:25 PM, Manger, James H <
[email-masked]> wrote:

> Some APIs (and certainly lots of web sites) use a mix of HTTPS and HTTP
> resources. Using the same bearer token for both sets of resources limits
> security of the HTTPS interactions to the insecurity of the HTTP ones.
> A better approach is to use separate tokens. Exposure of a token used on
> HTTP does not compromise the interactions on HTTPS.
>
> There is lots of existing practise with this approach: issuing 2 cookies
> when a user logs in: one marked "secure" and the other not. HTTP and HTTPS
> interactions can all be tied to the same user, but the HTTP ones don't
> reduce the security of the HTTPS ones.
>
> This mechanism is also useful when least-privilege tokens are wanted. For
> instance, one authorization flow can deliver different tokens with different
> scopes/permissions so only the minimum authority is exposed in specific API
> calls.
>
> This mechanism might also be useful when supporting different
> authentication algorithms (eg bearer token, HMAC-SHA1, CMAC-AES128...).
> Using the same secret with drastically different crypto algs is generally
> bad form. Separate tokens for each mechanism can be returned.
>
> This mechanism might be helpful for services with disparate collections of
> resource servers. A compromise at one host doesn't affect another if
> different tokens were issued for each.
>
> There have been other suggestions of repeated call to the token endpoint to
> upgrade/downgrade tokens. This mechanism doesn't preclude repeated calls,
> but it can avoid them in some circumstances.
>
> Any support?
> (If you don't like it, is it because you don't think there are enough cases
> where HTTP & HTTPS are mixed? Or is it the syntax?)
>
> --
> James Manger
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 14 May 2010 14:38:37 +1000

David,

> Why would we support bearer tokens over HTTP?
> Is someone planning to implement this?

Because the cookies-over-HTTP ~equivalent is widely used.
The spec does say SHOULD NOT, but also explicitly talks about how to do it.
the spec suggests limited scope and lifetime -- limited scope implies separate tokens for other scopes (eg for HTTPS).

[section 5 Accessing a Protected Resource]

   Access tokens SHOULD NOT be sent in the clear over an insecure channel.

   However, when it is necessary to transmit bearer tokens in the clear
   without a secure channel, authorization servers SHOULD issue access
   tokens with limited scope and lifetime to reduce the potential risk
   from a compromised access token.  Clients SHOULD request and utilize
   an access token with a matching secret when making protected resource
   requests over an insecure channel (e.g. an HTTP request without using
   TLS/SSL).

Even if you only support signed requests over HTTP you probably still want 2 tokens: a bearer token for HTTPS; a token+secret for HTTP.

[
  { "access_token":"Id87d6dDd", "sites":["https://api.example.org"] },
  { "access_token":"SlAV32hkKG", "sites":["http://api.example.org"],
       access_token_secret="386584633534" }
]

---

From: Dick Hardt <[email-masked]>
Date: Sun, 16 May 2010 11:44:28 -0700

Note that you could accomplish this functionality with the 'modify' proposal
I posted where an access token with a different scope could be requested
could be used to acquire a second token that has less privileges and would
be appropriate over HTTP.

To recap, 'modify' is like 'refresh' except the new scope is also passed as
a parameter.

-- Dick

On Thu, May 13, 2010 at 9:38 PM, Manger, James H <
[email-masked]> wrote:

> the spec suggests limited scope and lifetime -- limited scope implies
> separate tokens for other scopes (eg for HTTPS).
>
> Even if you only support signed requests over HTTP you probably still want
> 2 tokens: a bearer token for HTTPS; a token+secret for HTTP.
>
> [

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 17 May 2010 10:39:14 +1000

Dick,

> Note that you could accomplish this functionality with the 'modify' proposal I posted where an access token with a different scope could be requested could be used to acquire a second token that has less privileges and would be appropriate over HTTP.
>
> To recap, 'modify' is like 'refresh' except the new scope is also passed as a parameter.

The 'modify' proposal requires the client app to understand the server-specific scope values.

Otherwise a generic client app would, say:
1. get a token for HTTPS requests;
2. make an HTTP request (without the token);
3. receive 401 WWW-Auth.: Token ...;
4. have to decide if the existing token can be modified, or more user-consent is required.
5. make a 'modify' request;
6. re-try the HTTP request (with the new token).

That is possible -- if we define more flags and logic for OAuth's WWW-Auth response header (for step 4 above).
Returning an array of tokens is better in common situations -- regardless of whether or not the 'modify' proposal is also adopted.

--
James Manger

On Thu, May 13, 2010 at 9:38 PM, Manger, James H <[email-masked]> wrote:
David,

...

[