Subject: [OAUTH-WG] Variant of Web Server Flow w/o direct communication

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 20 Apr 2010 21:57:18 +0200

Hi all,

I would like to propose an additional variant of the Web Server Flow w/o 
the need for direct communication between client and authorization 
server in order to obtain authorized access/refresh tokens. Instead 
access and refresh tokens should directly be send back with the redirect 
to the client as it is the case in the User-Agent Flow.

As a major advantage the authorization server can be stateless with 
respect to authorization transaction data because there is no need to 
hold such data until the client obtains the tokens from the 
authorization server (callback, client, verification code, identity and 
so on). This simplifies the cluster/loadbalancing/fail-over architecture 
of the authorization server. Moreover, the load on the authz server 
should be reduced and the client saves the roundtrip time of the second 
call. This is even more important if clients extensively use the new 
"immediate" parameter to implement a SSO alike behavior and use this 
flow very often.

The pattern proposed can be found in SAML and is very similar to the 
OpenId authentication process.

Proposal: Add an optional parameter "verification_code" to the request 
(section 3.5.2.1.).

verification_code
OPTIONAL. The parameter value must be set to "true" or "false"
          (case sensitive). If set to "true" and the end user grants 
access,
          the redirection URI includes a code the client uses to obtain
         refresh and access token via a direct POST request. If set to
         "false" and the end user grants access, the redirection URI 
includes
         access and refresh token as well as the expires_in value in
         query parameters.
         Defaults to "true" if omitted.

Security Considerations

Threats:
A malicious client may pretend to be a legitimate client well-known to 
the authorization server. It may attain an access token approved by the 
end user and misuse it.

Countermeasures:
I see two potential countermeasures:
a) The response is encrypted with the client_secret and thus can only be 
decrypted by the legitmate client (similar to the way Kerberos handles 
such things).
- The authorization process is not refused early
- requires an encrypted container as parameter
+ identity theft is prevented
b) The request is signed (and thus authenticated) with an HMAC-256 based 
on the client_secret.
+ The inbound request can already be refused if a signature is missing 
or invalid.
- token data are sent over the use agent in plaint text (which might be 
acceptable since this are user data)

Is there support for this proposal?

regards,
Torsten.

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 20 Apr 2010 13:19:05 -0700

On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
<[email-masked]> wrote:
> As a major advantage the authorization server can be stateless with respect
> to authorization transaction data because there is no need to hold such data
> until the client obtains the tokens from the authorization server (callback,
> client, verification code, identity and so on). This simplifies the
> cluster/loadbalancing/fail-over architecture of the authorization server.

If making the authz server stateless is the major goal, you can
probably achieve that by encoding and encrypting all relevant data in
the verification code and set a short lifetime on it. Would that work?

> Moreover, the load on the authz server should be reduced and the client
> saves the roundtrip time of the second call. This is even more important if
> clients extensively use the new "immediate" parameter to implement a SSO
> alike behavior and use this flow very often.

True, there is a small gain here, but on the other hand you don't have
do deal with crypto.

Marius

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 20 Apr 2010 17:45:10 -0700

On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> the need for direct communication between client and authorization server in
> order to obtain authorized access/refresh tokens. Instead access and refresh
> tokens should directly be send back with the redirect to the client as it is
> the case in the User-Agent Flow.
>

Question (and sorry if I'm being dense) - what is the delta between Web
Server flow + verification_code=false and User-Agent flow?

> The pattern proposed can be found in SAML and is very similar to the OpenId
> authentication process.
>
>         (case sensitive). If set to "true" and the end user grants access,
>        "false" and the end user grants access, the redirection URI includes
> A malicious client may pretend to be a legitimate client well-known to the
> authorization server. It may attain an access token approved by the end user
> and misuse it.
>
> Countermeasures:
> decrypted by the legitmate client (similar to the way Kerberos handles such
> things).
> b) The request is signed (and thus authenticated) with an HMAC-256 based on
> the client_secret.
> + The inbound request can already be refused if a signature is missing or
> invalid.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Apr 2010 07:29:57 +0200

Am 21.04.2010 02:45, schrieb Evan Gilbert:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     I would like to propose an additional variant of the Web Server
>     Flow w/o the need for direct communication between client and
>     authorization server in order to obtain authorized access/refresh
>     tokens. Instead access and refresh tokens should directly be send
>     back with the redirect to the client as it is the case in the
>     User-Agent Flow.
>
>
> Question (and sorry if I'm being dense) - what is the delta between 
> Web Server flow + verification_code=false and User-Agent flow?

This is not a dense question :-)

The User Agent Flow adds the data as URL fragment which is not passed to 
the web server (as far as I understand). My proposal adds this data as 
URL query parameters, which are passed to the web server by the user agent.

I think the delta is small in terms of specification but the benefit for 
large-scale OAuth 2.0 deployments would be significant.

regards,
Torsten.

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 21 Apr 2010 08:31:47 -0700

On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt <
[email-masked]> wrote:

> the web server (as far as I understand). My proposal adds this data as URL
> query parameters, which are passed to the web server by the user agent.
>

At one point we had tokens in query string for the User-Agent flow, but
there were concerns about the security side. Query parameters are much more
likely to leak in logs and in referrers.

It's not a lot of work to support this functionality with the existing
User-Agent flow using a boilerplate response page. Page would:
1. Grab fragment
2. Make XMLHttpRequest with access token & refresh token to server, or POST
a form
3. Redirect to destination page.

Would this work?

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 21 Apr 2010 19:13:10 +0200

Am 21.04.2010 17:31, schrieb Evan Gilbert:
>
>
> On Tue, Apr 20, 2010 at 10:29 PM, Torsten Lodderstedt 
>>         I would like to propose an additional variant of the Web
>>         Server Flow w/o the need for direct communication between
>>         client and authorization server in order to obtain authorized
>>         access/refresh tokens. Instead access and refresh tokens
>>         should directly be send back with the redirect to the client
>>         as it is the case in the User-Agent Flow.
>>
>>
>>     Question (and sorry if I'm being dense) - what is the delta
>>     between Web Server flow + verification_code=false and User-Agent
>>     flow?
>
>     The User Agent Flow adds the data as URL fragment which is not
>     passed to the web server (as far as I understand). My proposal
>     adds this data as URL query parameters, which are passed to the
>     web server by the user agent.
>
>
> At one point we had tokens in query string for the User-Agent flow, 
> but there were concerns about the security side. Query parameters are 
> much more likely to leak in logs and in referrers.
>
> 2. Make XMLHttpRequest with access token & refresh token to server, or 
> POST a form

I think this would work but is IMHO somehow cumbersome and requires two 
requests to the service. Alternatively, the authorization server could 
directly respond with a HTML page containing a HTML form element with 
all response data. This form could automatically be submited to the 
service using JavaScript. This would be similar to OpenIds "HTML FORM 
Redirection".

regards,
Torsten.

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 21 Apr 2010 17:23:50 -0700

On Wed, Apr 21, 2010 at 10:13 AM, Torsten Lodderstedt <
[email-masked]> wrote:

> requests to the service.

I agree it's cumbersome. Hopefully the security folks can respond with the
pros/cons of tokens in the query parameters.

>  Alternatively, the authorization server could directly respond with a HTML
> page containing a HTML form element with all response data. This form could
> automatically be submited to the service using JavaScript. This would be
> similar to OpenIds "HTML FORM Redirection".
>

This is a good idea. Might make sense to support as a best practice - the
form can be static and it's fairly easy for any client to host it.

We recently had a similar discussion on the Native Application flow on the
OAuth WG thread - decided that we could implement the Native Flow as the Web
Server flow + a simple HTML web page. And the web page wouldn't be directly
part of the spec, but a separately documented best practice.

(note - I don't have strong opinions on this - mostly discussing options)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 24 Apr 2010 09:07:24 +0200

> the verification code and set a short lifetime on it. Would that work?

This would work if the goal is stateless design only. I would also like 
to save the second call. Since the protocol prescribes a second request 
to exchange the verification code into the tokens, libraries will 
perform this call.

> True, there is a small gain here, but on the other hand you don't have

Assessment of the gain might depend on the point of view. My point of 
view is the authorization server operator and the expected absolut 
request volume. I think a client can use OAuth in two ways.

(1) The client performs the authorization process, obtains and stores 
the long-living refresh token. Within a user session, this client 
retrieves the refresh token from its database, acquires a corresponding  
access token and access the service.

(2) The client does not store the refresh token. Instead in every client 
session, it initiates the OAuth authorization process again. The 
Authorization server authenticates the user, probably with SSO 
experience, and responds with the already existing refresh tokens and a 
new access token.

(1) has the characteristics of a setup process and will probably 
performed a few times per user over a long period. Let's assume a user 
base of 10 million users, where every user access 3 application/day. 
Tokens are valid for 1 year and application setup is uniformly 
distributed over the year. This ((10 million users * 3 apps) / 365 days) 
makes roughly 100 thousand authorization requests per day + 30 million 
refresh token requests.

(2) in contrast, this variant has the characteristics of a SSO solution. 
This would result in 60 million requests per day (10.000.000*2*3), 
instead. So variant (2) would double the load, which in the first place 
is a cost driver. My proposal will cut (2) down to 30 million requests.

Please correct me if I'm wrong.

Yes, you have to deal with crypto in order to implement my proposal. A 
lot of people seam to have problems with it, but others not. I mean 
cryptography is the foundation of reliable security. Yes it makes 
implementing applications harder, but sometimes you cannot circumvent it 
in order to achieve a protection or other goal (e.g. scalability, 
fault-tolerance, performance). Kerberos has shown sucessfully how to 
trade crypto for incredible performance and scalability. My proposal is 
intended as an variant of the flow, deployments are free to choose. I 
think most of them will use the simpler approch, but why not offering an 
option for the rest that is standard compliant, too? Without standard 
approval, there will no support in libraries, which make implementation 
even harder :-(

regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 24 Apr 2010 09:15:46 +0200

Am 22.04.2010 02:23, schrieb Evan Gilbert:
>
>>
>>     At one point we had tokens in query string for the User-Agent
>>     flow, but there were concerns about the security side. Query
>>     parameters are much more likely to leak in logs and in referrers.
>>
>>     It's not a lot of work to support this functionality with the
>>     existing User-Agent flow using a boilerplate response page. Page
>>     would:
>>     1. Grab fragment
>>     2. Make XMLHttpRequest with access token & refresh token to
>>     server, or POST a form
>     I think this would work but is IMHO somehow cumbersome and
>     requires two requests to the service.
>
>
> I agree it's cumbersome. Hopefully the security folks can respond with 
> the pros/cons of tokens in the query parameters.

I dicussed security considerations in my proposal. Depending on the risk 
assessment of the application/deployment, one will need to sign the 
request or encrypt the response.

>     Alternatively, the authorization server could directly respond
>     with a HTML page containing a HTML form element with all response
>     data. This form could automatically be submited to the service
>     using JavaScript. This would be similar to OpenIds "HTML FORM
>     Redirection".
>
>
> This is a good idea. Might make sense to support as a best practice - 
> the form can be static and it's fairly easy for any client to host it.
>
> We recently had a similar discussion on the Native Application flow on 
> the OAuth WG thread - decided that we could implement the Native Flow 
> as the Web Server flow + a simple HTML web page. And the web page 
> wouldn't be directly part of the spec, but a separately documented 
> best practice.
>

I don't know whether the flow can really be implemented w/o standard 
support.

1) The server has to decide when to respond with conventional redirect 
and when with  HTML FORM Redirection. This could probably be setup on a 
per client base.
2) The client may not perform the second call in order to retrieve the 
tokens. Instead it shall use the response parameters. I don't expect 
libraries to support this behavior as long as the standard does not 
specifies it.

regards,
Torsten.