[Openid-specs-ab] Reconsidering the proposal for User-Agent version of Connect

Breno de Medeiros breno at google.com
Fri Apr 22 15:46:44 UTC 2011

One of the topics we discussed during last conference call was the
User-Agent version of Connect in Google's proposal. Chuck pointed out
that pure javascript clients can't use a backchannel call.

If you remember the rationale for not returning the id_token jointly
with the access_token as the response of the end-user authorization
request was due to security concerns with token mismatch. However,
after many discussions in this forum I am concerned that the current
architecture with the backchannel call has severe drawbacks.

In examining the security issue further this week, I realized two things:

- All the security attacks that involve mismatched tokens can be
prevent with proper implementation of cross-site request forgery
protection in the app.
- OAuth2 itself is vulnerable to a number of similar attacks in the
absence of XSRF protection.

My recommendations are also twofold:

- We should use normative language in the document about client
implementation of XSRF protection, even if the server is not able to
validate that the client is compliant. A detailed security analysis
section of the document should clearly outline the risks and possible
- We should simplify the User-Agent flow of Connect by returning
id_token together with access_token. This will bring the User-Agent
flow closer to WebServer flow (where id_token is already returned with
access_token) and simplify various other discussions about how many
additional endpoints are needed for Connect.

What do you think?


More information about the Openid-specs-ab mailing list