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

Axel.Nennker at telekom.de Axel.Nennker at telekom.de
Fri Apr 22 16:40:50 UTC 2011


Are id_token and access token examples of an oauth2 request where the AS
returns multiple tokens?
And is connect than an extension to oauth2 that allows to request
multiple tokens?
Torsten discussed this on the oauth wg list but there was no real
response when I remember that correctly.
http://www.ietf.org/mail-archive/web/oauth/current/msg03639.html

I think it makes sense to request multiple tokens and the step from two
in our case to multiple is small if we define connect "right".

-Axel

> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net 
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf 
> Of Breno de Medeiros
> Sent: Friday, April 22, 2011 5:47 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Reconsidering the proposal for 
> User-Agent versionof Connect
> 
> 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