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

[Torsten Lodderstedt <[e-mail]>]

Am 20.04.2010 22:19, schrieb Marius Scurtescu:
> On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
> <[e-mail]>  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?
>    

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.

>
>    
>> 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.
>    

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.

> Marius
>