Subject: [OAUTH-WG] On the ease of writing an authorization server

From: Andrew Arnott <[email-masked]>
Date: Tue, 15 Jun 2010 08:19:18 -0700

I've read a few comments on this DL that a primary goal is that writing an
OAuth 2.0 client should be very easy.  I think we're doing well here.  I
know this ease for the client necessarily comes at the expense of some
complexity on the server.  As has also been pointed out recently (by Eran, I
believe) the AS' job is considerably more complex now than it was in OAuth
1.0.

While overall this *may* be a win, it also seems optimized for the few large
service providers that are driving the spec (Facebook, Twitter, etc.).  They
definitely have the resources and understanding that a large investment in
security is important.  But as more web sites across the Internet drop using
user passwords in favor of federated identity and/or OpenID-type protocols,
the only way these sites can delegate access to user data will be to use a
protocol like OAuth 2.0 since user passwords will no longer apply.
Therefore *very *many web sites will become OAuth 2.0 resource servers, and
likely given their size and requirements will be their on authorization
server as well.  Now we have a complex server-side protocol that may be
"too" complex for the average-sized web site to implement correctly and
confidently.

So my $0.02 here is that we try to keep the AS side simple as well where
possible.  And invite responses from others.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

---

From: David Recordon <[email-masked]>
Date: Tue, 15 Jun 2010 08:53:08 -0700

I frame this goal a little differently. When there is a decision about
where to place needed complexity, we should place as little as
possible of it on the client. This means that the AS is more complex,
but I think that is the correct decision.

--David

On Tue, Jun 15, 2010 at 8:19 AM, Andrew Arnott <[email-masked]> wrote:
> While overall this may be a win, it also seems optimized for the few large
> Therefore very many web sites will become OAuth 2.0 resource servers, and
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 15 Jun 2010 09:50:25 -0700

If the current draft is too hard for server developers to implement correctly, they should probably hire someone more capable. Server side development of a security protocol isn't something I'd like to see done by people without the proper experience. Once we have the security consideration section, this will become even more complex.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Tuesday, June 15, 2010 8:19 AM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] On the ease of writing an authorization server

I've read a few comments on this DL that a primary goal is that writing an OAuth 2.0 client should be very easy.  I think we're doing well here.  I know this ease for the client necessarily comes at the expense of some complexity on the server.  As has also been pointed out recently (by Eran, I believe) the AS' job is considerably more complex now than it was in OAuth 1.0.

While overall this may be a win, it also seems optimized for the few large service providers that are driving the spec (Facebook, Twitter, etc.).  They definitely have the resources and understanding that a large investment in security is important.  But as more web sites across the Internet drop using user passwords in favor of federated identity and/or OpenID-type protocols, the only way these sites can delegate access to user data will be to use a protocol like OAuth 2.0 since user passwords will no longer apply.  Therefore very many web sites will become OAuth 2.0 resource servers, and likely given their size and requirements will be their on authorization server as well.  Now we have a complex server-side protocol that may be "too" complex for the average-sized web site to implement correctly and confidently.

So my $0.02 here is that we try to keep the AS side simple as well where possible.  And invite responses from others.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 15 Jun 2010 09:40:57 -0700

Thanks, David.  Just to clarify, I think it is the right decision as well.
But I just wanted to voice that I think we should simplify the AS where
possible (i.e. where it doesn't sacrifice legitimate scenarios or simplicity
on the client).

As a great example of good work being done here, removing the access token
secrets was a great move IMO.  I wouldn't have liked it a few months ago,
but since it was among the more complex areas of the spec, hard to get
right, and no one was planning to use it (from the sound of it) moving it to
an extension spec makes tons of sense.