Subject: Re: [OAUTH-WG] Limiting signed requests to use the Authorization request header

From: George Fletcher <[email-masked]>
Date: Thu, 08 Apr 2010 10:08:31 -0400

Another use case is where a rich client wants to bootstrap a web session 
with the same identity (rich client to web SSO). Assuming that the web 
session will be established via OAuth with signatures, there is no way 
to fire up the browser with a "signed URL" if the OAuth parameters and 
signature need to be in a header.

As Jon mentions, the concept of allowing a service to create a signed 
URL and then pass it back to JS running in the browser, or invoking a 
browser directly is something that we leverage a lot across our rich 
clients and web applications.

I realize that these sorts of use cases are trivial if establishment of 
the SSO session switches from a signed mechanism to the OAuth WRAP 
bearer token model. The one nice feature of the signed URL is that it is 
one time use where the bearer token can be replayed multiple times.

Thanks,
George

Real world use case. Login into the latest AIM client. Click the mail 
icon/link.

On 3/31/10 7:25 AM, Moore, Jonathan wrote:
> What about a use case where the signature will be generated by one component but the request will be redeemed by another?
>
> For example, suppose there is a cross-domain JSONP call that requires authorization; in this case, I might have my client side code hit *my* origin server, obtain a signed URL, and then redeem it by hitting the JSONP resource. This has scaling advantages over having my origin proxy an OAuth request, and doesn't require me to have keys located on the client; I can keep them safely in my data centers.
>
> In this case, sending a "ready to redeem" signed request using the query parameter mechanism simplifies the client-side code. Furthermore, in this use case (cross-domain script inclusion), the client doesn't have the means to set the Authorization header (it can only include a<script>  element with a URL).
>
> A similar use case would be if you wanted to provide signed redirects (similarly useful for cross-domain functionality); browsers aren't going to modify the redirect URL they get back, or add an Authorization header to it.
>
> Jon
> ........
> Jon Moore
> Comcast Interactive Media
>
>
>
> -----Original Message-----
> From:[email-masked]  on behalf of Eran Hammer-Lahav
> Sent: Wed 3/31/2010 12:20 AM
> To: OAuth WG
> Subject: [OAUTH-WG] Limiting signed requests to use the Authorizationrequest header
>
> Since we have consensus that using signed requests is a more advance use
> case and will be used by more experienced developer, I would like to suggest
> we limit sending signed request parameters to the Authorization header (no
> URI query parameters or form-encoded body).
>
> This will not change the ability to send the oauth_token parameter in the
> query or body when using bearer tokens (as well as in the header). It will
> only apply to sending signed requests.
>
> The makes client request parameter much simpler as the only parameter
> "invading" the URI or body space of the request is oauth_token. Anything
> else is limited to the header.
>
> Thoughts? If you are not a fan, please reply with a use case.
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 07:41:01 -0700

Why is the native application launching a browser with a protected resource request? That seems odd.

Note that we currently have no plans of supporting signatures in any of the flows. We are discussing signatures only for using tokens with secrets when accessing protected resources.

EHL

On 4/8/10 7:08 AM, "George Fletcher" <[email-masked]> wrote:

Another use case is where a rich client wants to bootstrap a web session with the same identity (rich client to web SSO). Assuming that the web session will be established via OAuth with signatures, there is no way to fire up the browser with a "signed URL" if the OAuth parameters and signature need to be in a header.

As Jon mentions, the concept of allowing a service to create a signed URL and then pass it back to JS running in the browser, or invoking a browser directly is something that we leverage a lot across our rich clients and web applications.

I realize that these sorts of use cases are trivial if establishment of the SSO session switches from a signed mechanism to the OAuth WRAP bearer token model. The one nice feature of the signed URL is that it is one time use where the bearer token can be replayed multiple times.

Thanks,
George

Real world use case. Login into the latest AIM client. Click the mail icon/link.

In this case, sending a "ready to redeem" signed request using the query parameter mechanism simplifies the client-side code. Furthermore, in this use case (cross-domain script inclusion), the client doesn't have the means to set the Authorization header (it can only include a <script> element with a URL).

Jon
........
Jon Moore

-----Original Message-----
From: [email-masked] on behalf of Eran Hammer-Lahav
Sent: Wed 3/31/2010 12:20 AM
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorizationrequest header

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 8 Apr 2010 14:51:00 +0000

> Why is the native application launching a browser with a protected resource request? That seems odd.

Not odd at all a lot of the Eclipse applications can work this way

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Thursday, April 08, 2010 7:41 AM
To: George Fletcher; OAuth WG
Cc: Jonathan Moore
Subject: Re: [OAUTH-WG] Limiting signed requests to use the Authorization request header

EHL

Thanks,
George

Jon
........
Jon Moore

-----Original Message-----
From: [email-masked] on behalf of Eran Hammer-Lahav
Sent: Wed 3/31/2010 12:20 AM
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorizationrequest header

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Apr 2010 08:31:12 -0700

Can you share an example of a native application launching an external browser with a protect resource?

Why can't the end user just login to the browser using normal web login and access the resource?

EHL

EHL

Thanks,
George

Jon
........
Jon Moore

-----Original Message-----
From: [email-masked] on behalf of Eran Hammer-Lahav
Sent: Wed 3/31/2010 12:20 AM
To: OAuth WG
Subject: [OAUTH-WG] Limiting signed requests to use the Authorizationrequest header

EHL

---

From: George Fletcher <[email-masked]>
Date: Thu, 08 Apr 2010 14:30:50 -0400

> browser with a protect resource?
Native application = AIM
Protected Resource = User's AIM Mail box

AIM has supported this for a while.
> login and access the resource?
It's a better user experience to be seamlessly logged in than having to 
reenter credentials.

Thanks,
George
>     > Why is the native application launching a browser with a
>     protected resource request? That seems odd.
>
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Eran Hammer-Lahav
>     *Sent:* Thursday, April 08, 2010 7:41 AM
>     *To:* George Fletcher; OAuth WG
>     *Cc:* Jonathan Moore
>     *Subject:* Re: [OAUTH-WG] Limiting signed requests to use the
>     Authorization request header
>
>     Note that we currently have no plans of supporting signatures in
>     any of the flows. We are discussing signatures only for using
>     tokens with secrets when accessing protected resources.
>
>     EHL
>
>
>     Another use case is where a rich client wants to bootstrap a web
>     session with the same identity (rich client to web SSO). Assuming
>     that the web session will be established via OAuth with
>     signatures, there is no way to fire up the browser with a "signed
>     URL" if the OAuth parameters and signature need to be in a header.
>
>     As Jon mentions, the concept of allowing a service to create a
>     signed URL and then pass it back to JS running in the browser, or
>     invoking a browser directly is something that we leverage a lot
>     across our rich clients and web applications.
>
>     I realize that these sorts of use cases are trivial if
>     establishment of the SSO session switches from a signed mechanism
>     to the OAuth WRAP bearer token model. The one nice feature of the
>     signed URL is that it is one time use where the bearer token can
>     be replayed multiple times.
>
>     Thanks,
>     George
>
>     What about a use case where the signature will be generated by one
>     component but the request will be redeemed by another?
>
>     For example, suppose there is a cross-domain JSONP call that
>     requires authorization; in this case, I might have my client side
>     code hit *my* origin server, obtain a signed URL, and then redeem
>     it by hitting the JSONP resource. This has scaling advantages over
>     having my origin proxy an OAuth request, and doesn't require me to
>     have keys located on the client; I can keep them safely in my data
>     centers.
>
>     In this case, sending a "ready to redeem" signed request using the
>     query parameter mechanism simplifies the client-side code.
>     Furthermore, in this use case (cross-domain script inclusion), the
>     client doesn't have the means to set the Authorization header (it
>     can only include a <script> element with a URL).
>
>     A similar use case would be if you wanted to provide signed
>     redirects (similarly useful for cross-domain functionality);
>     browsers aren't going to modify the redirect URL they get back, or
>     add an Authorization header to it.
>
>     Jon
>     ........
>     Jon Moore

---

From: Allen Tom <[email-masked]>
Date: Thu, 08 Apr 2010 14:41:47 -0700

Yahoo has exactly the same use case.

The user is authenticated into the Yahoo Instant Messenger client
application, and clicks on the Yahoo Mail button to check Yahoo Mail.

Clicking the Mail button spawns a browser window with an authentication
token that is passed to the browser on the URL. The browser submits the
token to Yahoo¹s authentication server which validates the token, sets
authentication cookies to the browser, and then redirects the browser to
Yahoo Mail.

Allen

On 4/8/10 11:30 AM, "George Fletcher" <[email-masked]> wrote:

>>  Re: [OAUTH-WG] Limiting signed requests to use the Authorization request
>> header Can you share an example of a native application launching an external
>> browser with a protect resource?
>>  
> Native application = AIM
>> Why can¹t the end user just login to the browser using normal web login and
>> access the resource?
>>  
>>> Note that we currently have no plans of supporting signatures in any of the
>>> flows. We are discussing signatures only for using tokens with secrets when
>>> accessing protected resources.
>>>  
>>> EHL
>>>  
>>>  
>>> session will be established via OAuth with signatures, there is no way to
>>> fire up the browser with a "signed URL" if the OAuth parameters and
>>> As Jon mentions, the concept of allowing a service to create a signed URL
>>> and then pass it back to JS running in the browser, or invoking a browser
>>> directly is something that we leverage a lot across our rich clients and web
>>> applications.
>>>  
>>> I realize that these sorts of use cases are trivial if establishment of the
>>> SSO session switches from a signed mechanism to the OAuth WRAP bearer token
>>> model. The one nice feature of the signed URL is that it is one time use
>>> where the bearer token can be replayed multiple times.
>>>  
>>> Thanks,
>>> George
>>>  
>>> What about a use case where the signature will be generated by one component
>>> but the request will be redeemed by another?
>>>  
>>> For example, suppose there is a cross-domain JSONP call that requires
>>> authorization; in this case, I might have my client side code hit *my*
>>> origin server, obtain a signed URL, and then redeem it by hitting the JSONP
>>> resource. This has scaling advantages over having my origin proxy an OAuth
>>> request, and doesn't require me to have keys located on the client; I can
>>> keep them safely in my data centers.
>>>  
>>> In this case, sending a "ready to redeem" signed request using the query
>>> parameter mechanism simplifies the client-side code. Furthermore, in this
>>> use case (cross-domain script inclusion), the client doesn't have the means
>>> to set the Authorization header (it can only include a <script> element with
>>> a URL).
>>>  
>>> A similar use case would be if you wanted to provide signed redirects
>>> (similarly useful for cross-domain functionality); browsers aren't going to
>>> modify the redirect URL they get back, or add an Authorization header to it.
>>>  
>>> Jon
>>> ........
>>> Jon Moore

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 08 Apr 2010 18:09:27 -0400

Allen,

(I am a happy user of Yahoo mail via Verizon.) In some cases, especially 
if I had not used e-mail for a while, Yahoo prompts me to enter the 
password. Now, I think this is a very good feature, which would protect 
me if my computer is stolen. The question: how is this interworking with 
the case you explained?

Igor

Allen Tom wrote:
> Clicking the Mail button spawns a browser window with an 
> authentication token that is passed to the browser on the URL. The 
> browser submits the token to Yahoo’s authentication server which 
> validates the token, sets authentication cookies to the browser, and 
> then redirects the browser to Yahoo Mail.
>
> Allen
>
>
>         Re: [OAUTH-WG] Limiting signed requests to use the
>         Authorization request header Can you share an example of a
>         native application launching an external browser with a
>         protect resource?
>
>     Native application = AIM
>         Why can’t the end user just login to the browser using normal
>         web login and access the resource?
>
>     It's a better user experience to be seamlessly logged in than
>     having to reenter credentials.
>
>     Thanks,
>     George
>
>
>         EHL
>
>
>             *From:* [email-masked]
>             [mailto:[email-masked]] *On Behalf Of *Eran
>             Hammer-Lahav
>             *Subject:* Re: [OAUTH-WG] Limiting signed requests to use
>             the Authorization request header
>
>             Note that we currently have no plans of supporting
>             signatures in any of the flows. We are discussing
>             signatures only for using tokens with secrets when
>             Another use case is where a rich client wants to bootstrap
>             a web session with the same identity (rich client to web
>             SSO). Assuming that the web session will be established
>             via OAuth with signatures, there is no way to fire up the
>             browser with a "signed URL" if the OAuth parameters and
>             As Jon mentions, the concept of allowing a service to
>             create a signed URL and then pass it back to JS running in
>             the browser, or invoking a browser directly is something
>             that we leverage a lot across our rich clients and web
>             applications.
>
>             establishment of the SSO session switches from a signed
>             mechanism to the OAuth WRAP bearer token model. The one
>             nice feature of the signed URL is that it is one time use
>             What about a use case where the signature will be
>             generated by one component but the request will be
>             redeemed by another?
>
>             For example, suppose there is a cross-domain JSONP call
>             that requires authorization; in this case, I might have my
>             client side code hit *my* origin server, obtain a signed
>             URL, and then redeem it by hitting the JSONP resource.
>             This has scaling advantages over having my origin proxy an
>             OAuth request, and doesn't require me to have keys located
>             on the client; I can keep them safely in my data centers.
>
>             In this case, sending a "ready to redeem" signed request
>             using the query parameter mechanism simplifies the
>             client-side code. Furthermore, in this use case
>             (cross-domain script inclusion), the client doesn't have
>             the means to set the Authorization header (it can only
>             include a <script> element with a URL).
>
>             A similar use case would be if you wanted to provide
>             signed redirects (similarly useful for cross-domain
>             functionality); browsers aren't going to modify the
>             redirect URL they get back, or add an Authorization header
>             to it.
>
>             Jon
>             ........
>             Jon Moore
>     ------------------------------------------------------------------------
> ------------------------------------------------------------------------
>

---

From: Allen Tom <[email-masked]>
Date: Thu, 08 Apr 2010 16:17:40 -0700

Hi Igor,

Without getting into any specific details, most large websites will check
your browser cookies, along with other factors (including your IP address,
simultaneous sessions from other IP addresses, recent changes to your
account, the time you last verified your password, etc) to determine if your
browser is still authorized to access your Mail. When in doubt, the site
will verify your password to refresh the session before continuing.

Hope that helps,
Allen

On 4/8/10 3:09 PM, "Igor Faynberg" <[email-masked]> wrote:

>> browser submits the token to Yahoo¹s authentication server which
>>         Why can¹t the end user just login to the browser using normal

---

From: Brian Eaton <[email-masked]>
Date: Thu, 8 Apr 2010 21:58:51 -0700

> where the bearer token can be replayed multiple times.

Yep, Google does this kind of thing too.

Is there something that stops you from declaring that a particular
token is single use?

1) Client makes call to Authorization server, passing in either the
refresh token or an access token (depending on the security model you
want.)
2) AS returns a token.
3) Client uses the token to pop open a web browser.

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 09 Apr 2010 09:42:06 +0200

As far as I understand, this use case could also be implemented using 
bearer tokens. Am I wrong?

I assume the benefit of using signed GET requests is a better protection 
against abuse of the token if the URL is spread via log files or 
Referer-Headers. But this measure obliges the receiver to implement a 
stateful reply detection.

regards,
Torsten.

Am 09.04.2010 06:58, schrieb Brian Eaton:
> On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher<[email-masked]>  wrote:
>

---

From: George Fletcher <[email-masked]>
Date: Fri, 09 Apr 2010 10:30:12 -0400

Yes, this is possible, though to be secure it should really happen over 
SSL which is less of a requirement for a signed request.

I guess the main question is whether we really need to remove the 
signature related parameters from URL and only allow them in the 
Authorization header. For signed requests, these use cases pretty much 
require that the signature parameters be allowed in the URL.

Obviously, if we change our model to not use signed URLs then this issue 
goes away:)

Thanks,
George

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 09 Apr 2010 10:43:05 -0400

Yes, it does, thanks!

It makes me think that the Security Considerations text should include 
something along the lines that OAuth does not exclude (or maybe even 
"encourages" instead of "does not exclude") multi-factor authentication, 
which can mitigate cases where the present security mechanisms deem 
insufficient.

Igor

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 10:39:32 -0700

In practice this is the same as logging in which I expect to require SSL anyway. Signed or not, attackers should not be able to login to your email account simply by using a MITM attack when you click on your IM client. So SSL is required already.

EHL

On 4/9/10 7:30 AM, "George Fletcher" <[email-masked]> wrote:

Yes, this is possible, though to be secure it should really happen over SSL which is less of a requirement for a signed request.

I guess the main question is whether we really need to remove the signature related parameters from URL and only allow them in the Authorization header. For signed requests, these use cases pretty much require that the signature parameters be allowed in the URL.

Obviously, if we change our model to not use signed URLs then this issue goes away:)

Thanks,
George

On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email-masked]> <mailto:[email-masked]>  wrote:

Cheers,
Brian

---

From: "Moore, Jonathan" <[email-masked]>
Date: Fri, 9 Apr 2010 21:34:42 -0400

However, this doesn't address my earlier use case of a signed, cross- 
domain JSONP call, especially if it's sitting on a non-HTTPS page; I  
need to make a non-HTTP XHR request to obtain a (signed or tokenized)  
URL to include in my <script> include, so requiring a bearer token and  
SSL basically forces me to have the whole page delivered over HTTPS,  
which may be overkill for my application.

While I can understand that token and secret acquisition might need  
SSL, always requiring it on authorized requests too seems too much.

Can someone explain/re-explain why query parameter signatures need to  
be eliminated? The Authorization header is great when you can  
manipulate it, but you can't always. Why is it problematic for the  
signatures to be able to appear in either place?

Jon

........
Jon Moore

On Apr 9, 2010, at 1:39 PM, "Eran Hammer-Lahav" <[email-masked]>  
wrote:

> In practice this is the same as logging in which I expect to require  
> SSL anyway. Signed or not, attackers should not be able to login to  
> your email account simply by using a MITM attack when you click on  
> your IM client. So SSL is required already.
>
> EHL
>
>
> Yes, this is possible, though to be secure it should really happen  
> over SSL which is less of a requirement for a signed request.
>
> Authorization header. For signed requests, these use cases pretty  
> much require that the signature parameters be allowed in the URL.
>
> On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email-masked]> <mailto:[email-masked] 
> >  wrote:
>
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Apr 2010 22:27:44 -0700

Its a more complicated spec in both detail and how signatures are created.

The fact that the URI or body includes both resource parameters and token/signature parameters makes it necessary to parse and sort the parameters, deal with encoding, etc. If we limit signed request to the header, then all the protocol parameters are separate from the API request and we can sign it with little normalization by treating the request URI and form-encoded-body (typically a short single string) as opaque strings.

Supporting URI query and form-body for bearer token means adding a single (simple) parameter to the request: oauth_token=something. Adding the signature parameters mean at least 5 (token, signature, timestamp, nonce, algorithm).

You can always extend the protocol. Moving this feature elsewhere is a worthy optimization to make signatures (and the overall spec) easier to understand.

EHL

On 4/9/10 6:34 PM, "Jonathan Moore" <[email-masked]> wrote:

However, this doesn't address my earlier use case of a signed, cross-domain JSONP call, especially if it's sitting on a non-HTTPS page; I need to make a non-HTTP XHR request to obtain a (signed or tokenized) URL to include in my <script> include, so requiring a bearer token and SSL basically forces me to have the whole page delivered over HTTPS, which may be overkill for my application.

While I can understand that token and secret acquisition might need SSL, always requiring it on authorized requests too seems too much.

Can someone explain/re-explain why query parameter signatures need to be eliminated? The Authorization header is great when you can manipulate it, but you can't always. Why is it problematic for the signatures to be able to appear in either place?

Jon

........
Jon Moore

On Apr 9, 2010, at 1:39 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

On 4/9/10 7:30 AM, "George Fletcher" <[email-masked] <mailto:[email-masked]> > wrote:

Thanks,
George

On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email-masked] <mailto:[email-masked]> > <mailto:[email-masked] <mailto:[email-masked]> >  wrote:

Cheers,
Brian

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 10 Apr 2010 09:30:41 +0200

From my point of view, your use case can be implemented in two ways

1) tokenized & signed URLs provided by your origin server
2) URLs with one-time usage bearer tokens as parameter acquired by your 
origin server

I see the following pros/cons:

Load: (2) requires the origin server to acquire one token per link on 
your page from the auth server, which may cause a lot of load on the 
authz server :-(. (1) only needs to obtain a single token since the 
signature is calculated by the origin server locally. This might be much 
better from a load perspective.

Security: As a further downside (2) either requires HTTPS communication 
for the whole page or you acquire the URL with one-time usage bearer 
token over HTTP. Acquisition from authz server can still be performed 
over HTTPS. If this acceptable depends on your security considerations.

Comments?

regards,
Torsten.

Am 10.04.2010 03:34, schrieb Moore, Jonathan:
> However, this doesn't address my earlier use case of a signed, 
> cross-domain JSONP call, especially if it's sitting on a non-HTTPS 
> page; I need to make a non-HTTP XHR request to obtain a (signed or 
> tokenized) URL to include in my <script> include, so requiring a 
> bearer token and SSL basically forces me to have the whole page 
> delivered over HTTPS, which may be overkill for my application.
>
> On Apr 9, 2010, at 1:39 PM, "Eran Hammer-Lahav" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> On 4/9/10 7:30 AM, "George Fletcher" <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Yes, this is possible, though to be secure it should really
>>     happen over SSL which is less of a requirement for a signed request.
>>
>>         On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher
>>         <[email-masked] <mailto:[email-masked]>>
>>         <mailto:[email-masked]>  wrote:
>>
>>
>>
>>             establishment of the
>> [email-masked] <mailto:[email-masked]>

---

From: "Moore, Jonathan" <[email-masked]>
Date: Sat, 10 Apr 2010 09:13:47 -0400

Ok, thanks - I was missing the possibility that bearer tokens could be  
single use. I agree this covers my use case adequately, so I am now  
definitely +1 for simplifying the spec in this way.

Thanks for bearing (pun intended) with me.

Jon

........
Jon Moore

On Apr 10, 2010, at 3:30 AM, "Torsten Lodderstedt" <[email-masked] 

> 2) URLs with one-time usage bearer tokens as parameter acquired by  
> your origin server
>
> Load: (2) requires the origin server to acquire one token per link  
> on your page from the auth server, which may cause a lot of load on  
> the authz server :-(. (1) only needs to obtain a single token since  
> the signature is calculated by the origin server locally. This might  
> be much better from a load perspective.
>
> Security: As a further downside (2) either requires HTTPS  
> communication for the whole page or you acquire the URL with one- 
> time usage bearer token over HTTP. Acquisition from authz server can  
> still be performed over HTTPS. If this acceptable depends on your  
> security considerations.
>
> Comments?
>
> regards,
> Torsten.
>
>> delivered over HTTPS, which may be overkill for my application.Â
>>
>> Can someone explain/re-explain why query parameter signatures need  
>> to be eliminated? The Authorization header is great when you can  
>>> In practice this is the same as logging in which I expect to  
>>> require SSL anyway. Signed or not, attackers should not be able to  
>>> login to your email account simply by using a MITM attack when you  
>>> click on your IM client. So SSL is required already.
>>>
>>> EHL
>>>
>>>
>>> On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email-masked]>  
>>> <mailto:[email-masked]> Â wrote:
>>> Â Â
>>> Â
>>>
>>> Â Â Â Â
>>> Â
>>> Â Â

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 11 Apr 2010 21:05:57 +0200

I don't know if we are really done. Does the current draft already 
consider one-time tokens? How does a client acquire one-time tokens?

Moreover, I would prefer the signature solution because of the increase 
in load caused by the acquisition of multiple one-time tokens.

Apart from that, another possible solution occured to me. Would it be 
possible to use a cookie containg a token instead of constructing URLs 
carrying different tokens?

The origin server could acquire an ordinary bearer token and store it 
within a cookie. If the JavaScript code sends HTTP requests and the 
target domain matches the browser should automatically add the cookie to 
every call thus sending the token with every request. The origin server 
would need to refresh the token periodically in order to prevent abuse 
of the token.

Would this work?

regards,
Torsten.

Am 10.04.2010 15:13, schrieb Moore, Jonathan:
> On Apr 10, 2010, at 3:30 AM, "Torsten Lodderstedt" 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> signature is calculated by the origin server locally. This might be 
>> much better from a load perspective.
>>
>> communication for the whole page or you acquire the URL with one-time 
>> usage bearer token over HTTP. Acquisition from authz server can still 
>> be performed over HTTPS. If this acceptable depends on your security 
>> considerations.
>>
>> Comments?
>>
>> regards,
>> Torsten.
>>
>>>>     I guess the main question is whether we really need to remove
>>>>     the signature related parameters from URL and only allow them
>>>>     in the Authorization header. For signed requests, these use
>>>>     cases pretty much require that the signature parameters be
>>>>     allowed in the URL.
>>>>

---

From: "Moore, Jonathan" <[email-masked]>
Date: Sun, 11 Apr 2010 19:54:39 -0400

Actually, in this case, I'm imagining a base page that is heavily  
cached (and non-personalized), perhaps delivered by CDN, non-SSL. The  
rendered page then wants to make an authorized cross-domain call to  
the Service Provider, personalized to the currently logged-in user.

I don't think one-time bearer tokens are appropriate here, because I  
would need to send the user through a refresh or reacquisition flow  
for every call, which kind of defeats the point.

I am ok with this generating a non-HTTP AJAX origin request to obtain  
a tokenized or signed URL; this can likely be served without  
significant I/O if I have the appropriate tokens and secrets cached in  
memory. However, the resulting URL must be redeemable without access  
to the Authorization header, as I'm going to need to include it in a  
<script> tag (equivalently, make the JSONP call with a script insert  
against the origin that redirects to the authorized resource -- again,  
no access to the Authorization header).

For scale reasons, I don't want to proxy the call through my origin;  
that holds the origin request open while I am waiting for the Service  
Provider to return.

Cookies don't work here, because I as the origin can't set cookies for  
the SP's domain.

As I think about it here, I don't think bearer tokens are appropriate,  
as they require SSL for this sequence to work.

While I can appreciate that the spec is much simpler without the query  
parameter signatures, I think I'm back to needing to be convinced that  
my use case can be addressed without them and with similar operational  
and scaling characteristics to what is available in OAuth 1.0a.

"As simple as possible, but no simpler."

Jon
........
Jon Moore

On Apr 11, 2010, at 3:06 PM, "Torsten Lodderstedt" <[email-masked] 

> Moreover, I would prefer the signature solution because of the  
> increase in load caused by the acquisition of multiple one-time  
> tokens.
>
> Apart from that, another possible solution occured to me. Would it  
> be possible to use a cookie containg a token instead of constructing  
> URLs carrying different tokens?
>
> The origin server could acquire an ordinary bearer token and store  
> it within a cookie. If the JavaScript code sends HTTP requests and  
> the target domain matches the browser should automatically add the  
> cookie to every call thus sending the token with every request. The  
> origin server would need to refresh the token periodically in order  
> to prevent abuse of the token.
>
> Would this work?
>
> regards,
> Torsten.
>
>> Ok, thanks - I was missing the possibility that bearer tokens could  
>> be single use. I agree this covers my use case adequately, so I am  
>> now definitely +1 for simplifying the spec in this way.
>>
>>> on your page from the auth server, which may cause a lot of load  
>>> on the authz server :-(. (1) only needs to obtain a single token  
>>> since the signature is calculated by the origin server locally.  
>>> This might be much better from a load perspective.
>>>
>>> time usage bearer token over HTTP. Acquisition from authz server  
>>> can still be performed over HTTPS. If this acceptable depends on  
>>> your security considerations.
>>>
>>> Comments?
>>>
>>> regards,
>>> Torsten.
>>>
>>>> cross-domain JSONP call, especially if it's sitting on a non- 
>>>> HTTPS page; I need to make a non-HTTP XHR request to obtain a  
>>>> (signed or tokenized) URL to include in my <script> include, so  
>>>> requiring a bearer token and SSL basically forces me to have the  
>>>> whole page delivered over HTTPS, which may be overkill for my  
>>>> application.Ã‚Â
>>>>
>>>> While I can understand that token and secret acquisition might  
>>>> need SSL, always requiring it on authorized requests too seems  
>>>> too much.
>>>>
>>>> Can someone explain/re-explain why query parameter signatures  
>>>> need to be eliminated? The Authorization header is great when you  
>>>> can manipulate it, but you can't always. Why is it problematic  
>>>> for the signatures to be able to appear in either place?
>>>>
>>>> Jon
>>>>
>>>> ........
>>>> Jon Moore
>>>>
>>>>
>>>>> require SSL anyway. Signed or not, attackers should not be able  
>>>>> to login to your email account simply by using a MITM attack  
>>>>> when you click on your IM client. So SSL is required already.
>>>>>
>>>>> EHL
>>>>>
>>>>>
>>>>> the signature related parameters from URL and only allow them in  
>>>>> the Authorization header. For signed requests, these use cases  
>>>>> pretty much require that the signature parameters be allowed in  
>>>>> the URL.
>>>>>
>>>>> <[email-masked]> <mailto:[email-masked]> Ã‚Â wrote:
>>>>> Ã‚Â Ã‚Â
>>>>> Ã‚Â
>>>>>
>>>>> Ã‚Â Ã‚Â Ã‚Â Ã‚Â
>>>>> Ã‚Â
>>>>> Ã‚Â Ã‚Â

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 11 Apr 2010 23:03:20 -0700

Hi Jon,

Purely from a process perspective, the same goes with convincing that this
use case is core to the protocol. There is already a list of things the core
spec does not support (language preference, re-delegation, body signatures,
asymmetric secrets, discovery, UI features) which people want it to support.
I think part of the discussion should include whether this is *possible* to
accomplish with an extension.

For example, a way to encode the entire Authorization header into the
oauth_token parameter (or a different parameter):

  GET /resource?oauth_token=vF9dft4qmT;nonce;timestamp;algorithm;signature
HTTP/1.1
  Host: server.example.com

Alternatively, the extension can require that any oauth_ parameters be added
at the end of the query and removed by the server to recreate the header
before calculating signatures.

It would be helpful to hear from others if they have more use cases which
require signed requests with parameters outside the header. Also, this will
be a bit more practice to discuss once we have a proposal for signatures
that is simpler than 1.0a (so we can decide whether that simplification
helps and worth the limitation in core).

EHL

On 4/11/10 4:54 PM, "Jonathan Moore" <[email-masked]> wrote:

> Actually, in this case, I'm imagining a base page that is heavily cached (and
> non-personalized), perhaps delivered by CDN, non-SSL. The rendered page then
> wants to make an authorized cross-domain call to the Service Provider,
> personalized to the currently logged-in user.
> 
> I don't think one-time bearer tokens are appropriate here, because I would
> need to send the user through a refresh or reacquisition flow for every call,
> which kind of defeats the point.
> 
> I am ok with this generating a non-HTTP AJAX origin request to obtain a
> tokenized or signed URL; this can likely be served without significant I/O if
> I have the appropriate tokens and secrets cached in memory. However, the
> resulting URL must be redeemable without access to the Authorization header,
> as I'm going to need to include it in a <script> tag (equivalently, make the
> JSONP call with a script insert against the origin that redirects to the
> authorized resource -- again, no access to the Authorization header).
> 
> For scale reasons, I don't want to proxy the call through my origin; that
> holds the origin request open while I am waiting for the Service Provider to
> return.
> 
> Cookies don't work here, because I as the origin can't set cookies for the
> SP's domain.
> 
> As I think about it here, I don't think bearer tokens are appropriate, as they
> require SSL for this sequence to work.
> 
> parameter signatures, I think I'm back to needing to be convinced that my use
> case can be addressed without them and with similar operational and scaling
> characteristics to what is available in OAuth 1.0a.
> 
> On Apr 11, 2010, at 3:06 PM, "Torsten Lodderstedt" <[email-masked]>
> wrote:
> 
>> I don't know if we are really done. Does the current draft already consider
>> one-time tokens? How does a client acquire one-time tokens?
>> 
>> Moreover, I would prefer the signature solution because of the increase in
>> load caused by the acquisition of multiple one-time tokens.
>> 
>> The origin server could acquire an ordinary bearer token and store it within
>> a cookie. If the JavaScript code sends HTTP requests and the target domain
>> matches the browser should automatically add the cookie to every call thus
>> sending the token with every request. The origin server would need to refresh
>> the token periodically in order to prevent abuse of the token.
>> 
>> Would this work?
>> 
>> regards,
>> Torsten.
>> 
>>> <mailto:[email-masked]> > wrote:
>>>  
>>>  
>>>  
>>>>  
>>>> Load: (2) requires the origin server to acquire one token per link on your
>>>> page from the auth server, which may cause a lot of load on the authz
>>>> server :-(. (1) only needs to obtain a single token since the signature is
>>>> calculated by the origin server locally. This might be much better from a
>>>> load perspective.
>>>>  
>>>> Security: As a further downside (2) either requires HTTPS communication for
>>>> the whole page or you acquire the URL with one-time usage bearer token over
>>>> HTTP. Acquisition from authz server can still be performed over HTTPS. If
>>>> this acceptable depends on your security considerations.
>>>>  
>>>> Comments?
>>>>  
>>>> regards,
>>>> Torsten.
>>>>  
>>>>> cross-domain JSONP call, especially if it's sitting on a non-HTTPS page; I
>>>>> need to make a non-HTTP XHR request to obtain a (signed or tokenized) URL
>>>>> to include in my <script> include, so requiring a bearer token and SSL
>>>>> basically forces me to have the whole page delivered over HTTPS, which may
>>>>> be overkill for my application.Ã‚Â
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>> While I can understand that token and secret acquisition might need SSL,
>>>>> always requiring it on authorized requests too seems too much.
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>> Can someone explain/re-explain why query parameter signatures need to be
>>>>> eliminated? The Authorization header is great when you can manipulate it,
>>>>> but you can't always. Why is it problematic for the signatures to be able
>>>>> to appear in either place?
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>> Jon
>>>>>  
>>>>> 
>>>>> ........ 
>>>>> Jon Moore
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>>  
>>>>> 
>>>>> <mailto:[email-masked]> > wrote:
>>>>>  
>>>>>  
>>>>>  
>>>>>>  
>>>>>> In practice this is the same as logging in which I expect to require SSL
>>>>>> anyway. Signed or not, attackers should not be able to login to your
>>>>>> email account simply by using a MITM attack when you click on your IM
>>>>>> client. So SSL is required already.
>>>>>>  
>>>>>> EHL 
>>>>>>  
>>>>>>  
>>>>>> <mailto:[email-masked]> > wrote:
>>>>>>  
>>>>>>   
>>>>>>>> On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email-masked]
>>>>>>>> <mailto:[email-masked]> > <mailto:[email-masked]
>>>>>>>> <mailto:[email-masked]> > Ã‚Â wrote:
>>>>>>>> Ã‚Â Ã‚Â 
>>>>>>>> Ã‚Â 
>>>>>>>>   
>>>>>>>>  
>>>>>>>> the
>>>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>  
>>>>>>  
>>>>>  
>>>>> 
>>>>> <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>   
>>>>>  
>>>>  
>>>>  
>>>>  
>> 
>

---

From: "Moore, Jonathan" <[email-masked]>
Date: Mon, 12 Apr 2010 10:07:50 -0400

Hi Eran,

I'm not sure it is fair to include this request in with the "there's a lot of things people want the core protocol to support", because this is something that is available in 1.0a that we're considering taking away.

To be clear, I'm not as concerned with exact backwards compatibility (i.e. using exactly the same query parameter signature scheme from 1.0a) if I can get "functionality backwards-compatibility". In other words, if there's another way to accomplish what I'm trying to do within the new spec, then that works for me.

Your proposal below (encode the contents of the Authorization header within the URI somewhere) is interesting and might fit the bill. I wonder if there's a broader extension which would allow lifting the exact contents of the Authorization header into a query parameter, to allow for "pre-authorized" GET requests, whether they use OAuth or not. I may reach out to the HTTP WG about that.

Jon

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Monday, April 12, 2010 2:03 AM
To: Moore, Jonathan
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Limiting signed requests to use the Authorization request header

Hi Jon,

EHL

On 4/11/10 4:54 PM, "Jonathan Moore" <[email-masked]> wrote:

>>>>> be overkill for my application.Ã'Â
>>>>>  
>>>>> 
>>>>>  
>>>>>  
>>>>>>>> <mailto:[email-masked]> > Ã'Â wrote:
>>>>>>>> Ã'Â Ã'Â 
>>>>>>>> Ã'Â 
>>>>>>>>   
>>>>>>>>  
>>>>>>>> Ã'Â Ã'Â Ã'Â Ã'Â
>>>>>>>> Ã'Â 
>>>>>>>> Ã'Â Ã'Â