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

John Bradley ve7jtb at ve7jtb.com
Fri Apr 22 20:56:12 UTC 2011


I am not a big fan of the user agent flow for websites.    
The problem to my mind is passing the access token through the browser where the user can cut and paste it, or it can be intercepted.

I don't think using the access token to retrieve the ID_token is necessarily that much of an improvement.

It may be best to keep it simple and return both tokens through the browser but explain the security issues.

If it is a real smart agent in the browser that is going to use the token then that flow is a good thing.  
I think the Web server/code flow is better for the web server /SSO use case.

To make the user agent flow as secure, you need to encrypt the tokens to the RP, and I don't know that we have a sufficient use case for that.

So I am OK with returning the access and ID token together in that flow, with appropriate security warnings.

I will probably forbid a Gov RP from using it however. (not a problem as I see it)

John B.



On 2011-04-22, at 11:46 AM, Breno de Medeiros wrote:

> 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
> mitigations.
> - 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?
> 
> -- 
> --Breno
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab



More information about the Openid-specs-ab mailing list