Subject: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)

From: Murali VP <[email-masked]>
Date: Tue, 25 May 2010 13:43:40 -0700

Anyway to find out what the outcome was from the May 20th interim meeting? I
wanted to participate but had to be at Google I/O.

3.5.  User-Agent Flow

1. Since the client_id is public, the only check that prevents from
any client posing as a registered client is the redirect_uri, this is
fine, except that if client web application has numerous domains, each
domain should register and have a separate client_id which is a pain.
The alternative of a single redirect_uri returning a 302 won't work
since the fragment will no more be available (I guess there are ways
to get around this).

2. It is not clear from the draft how a user agent flow would refresh
an access token. As per section 4, client does a HTTP(S) POST to
authorization server which seems to return a 200 to user-agent if the
request was successful leaving the user-agent in authorization
server's domain with a JSON response data! If user-agent flow cannot
refresh access token, why did it send the refresh_token in the first
place in the fragment?

3. The draft doesn't seem to mention how a client in the user-agent
can make protected resource requests given that such requests would be
cross domain. The only viable option seems to be JSONP requests (eg.
Facebook). The specification should include some material describing
protected resource requests in the user-agent flow case.

A relatively less important question:

Since the request token has been eliminated, the web server flow (3.6)
which comes close to the widely adopted OAuth 1.0's 3-legged oauth
flow but without much of a dance isn't backward compatible, is this a
known decision?

---

From: Allen Tom <[email-masked]>
Date: Tue, 25 May 2010 19:16:35 -0700

Yes  one of the design goals for Oauth-WRAP was to eliminate the request
token. 

It is very tricky for SPs to implement the Request Token due to data
replication issues. The Request token could be issued to the client in one
data center, and then immediately submitted by the browser to a different
data center. This means that the data has to be very quickly replicated.

On the client side of things, if the AS¹s approval screen is displayed in a
popup window (like Facebook Connect) - it could be tricky to tricky for the
client to pre-fetch the request token before displaying the ³Connect² button
in order to get around popup blockers.

Allen

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 26 May 2010 11:45:14 -0400

Allen,

If the explicit action of the Client sending a Request Token
is removed, how does OAuth do logging and auditing?

/thomas/

__________________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Allen Tom
Sent: Tuesday, May 25, 2010 10:17 PM
To: Murali VP; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.0 questions/suggestions (based on draft 2-05)

Yes - one of the design goals for Oauth-WRAP was to eliminate the request token.

It is very tricky for SPs to implement the Request Token due to data replication issues. The Request token could be issued to the client in one data center, and then immediately submitted by the browser to a different data center. This means that the data has to be very quickly replicated.

On the client side of things, if the AS's approval screen is displayed in a popup window (like Facebook Connect) - it could be tricky to tricky for the client to pre-fetch the request token before displaying the "Connect" button in order to get around popup blockers.

Allen

---

From: Allen Tom <[email-masked]>
Date: Wed, 26 May 2010 17:37:34 -0700

Hi Thomas,

I don¹t understand why there would be an issue regarding logging and
auditing if there¹s no Request Token, as in Oauth 1.0.

An OAuth2 Auth Server can audit that the user approved the request when the
user approves the request after the client redirects the browser to the
End-User Endpoint (Section 3.2 in Draft 5).

In most of the flows, the client the client is required to submit the
verification code that the AS sent to the client¹s redirect_uri in order to
get the Access Token to get  the user¹s data. The AS can also audit/log when
the access token was returned to the client.

I think that Service Providers can log/audit

1. The user¹s approval of the request
2. The client¹s request for the Access Token
3. The client¹s use of the Access Token to fetch a Protected Resource

I don¹t think that the removal of the Oauth 1.0 request token really affects
logging/auditing  perhaps I¹m missing something?

Thanks
Allen

On 5/26/10 8:45 AM, "Thomas Hardjono" <[email-masked]> wrote:

> data center, and then immediately submitted by the browser to a different data
> center. This means that the data has to be very quickly replicated.
>

---

From: Evan Gilbert <[email-masked]>
Date: Wed, 26 May 2010 20:51:57 -0700

> since the fragment will no more be available (I guess there are ways

You can have a single redirect_uri that does a client side redirect using
JavaScript. The only catch is that this is dangerous from a security
perspective - your additional redirect needs to have strict rules about the
domains it can forward to - so this should be considered a power-developer
technique and we need to write up best practices or better provide a JS
library that has gone through review.

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Murali VP <[email-masked]>
Date: Thu, 27 May 2010 10:08:37 -0700

> library that has gone through review.
Agree with you, based on the fact that the access_token is sent in the
fragment and not as a query parameter attached to the redirect_uri implies
that the access_token is not meant to be sent to the client's web server, so
the forwarding cannot result in sending the access_token but should continue
to attach the fragment which the forwarded to domain should still have a
script to read and use the access_token in the fragment.