Am 20.04.2010 22:19, schrieb Marius Scurtescu:
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
<[email protected]> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
