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