On Oct 17, 2014, at 8:25 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> +1. I'm finding this write-up summarizing the "OAuth2 and Authentication" > 'situation' perfectly. It does help. > > Minor suggestions/questions: > - might make sense to point out that an id_token can be linked to the access > token (via at_hash), thus confirming both tokens came from the same AS Seems a reasonable point, I can add that. > - should a 2-way TLS mentioned as a possible approach for mitigating the > 'injection of the token' attack ? I guess it won't scale really well but IMHO > it is a useful mechanism nonetheless It doesn't actually help in this case, since if the client is checking the server's certs that should be OK (or as OK as TLS can get). The real attack comes from someone handing the token to an application through a mechanism other than the return from the token endpoint, and I've seen a handful of applications that pass around the access token to themselves through internal callback mechanisms that are a bit more exposed than they ought to be. > - should a few words be reserved for the client credentials flow - this is of > course not a mainstream OAuth2 nor its related to OIDC but it is all about > the authentication IMHO, the clients get their tokens by simply getting > authenticated, and as far as legacy (code) clients are concerned they > 'migrate' from sending the name/password to the resource endpoint on every > request ? The client credentials flow has nothing to do with user authentication, which is why it's left out of OIDC. There might not even be a user in this flow (and it's generally assumed that there isn't). > - IMHO it would be useful to mention that OIDC RP can help non-OAuth2 > servers, i.e one does not have to write an OAuth2 client web application to > get the benefits of the OIDC-driven authentication I don't understand what you're saying here. In order to make an OIDC RP, you need to write an OAuth2 client. That's by design. -- Justin > > Thanks, Sergey > On 16/10/14 17:54, Hannes Tschofenig wrote: >> Participants: >> >> * Brian Campbell >> * John Bradley >> * Derek Atkins >> * Phil Hunt >> * William Kim >> * Josh Mandel >> * Hannes Tschofenig >> >> >> Notes: >> >> Justin distributed a draft writeup and explained the reasoning behind >> it. The intended purpose is to put the write-up (after enough review) on >> oauth.net. See attachments. Justin solicited feedback from the >> conference call participants and from the working group. >> >> One discussion item was specifically related to the concept of audience >> restrictions, which comes in two flavours: (a) restriction of the access >> token regarding the resource server and (b) restriction of the id token >> regarding the client. Obviously, it is necessary to have both of these >> audience restrictions in place and to actually check them. >> >> The group then went into a discussion about the use of pseudonyms in >> authentication and the problems deployments ran into when they used >> pseudonyms together with a wide range of attributes that identified >> users nevertheless. Phil suggested to produce a write-up about this topic. >> >> Finally, the group started a discussion about potential actions for the >> OAuth working groups. Two activities were mentioned, namely to produce >> an IETF draft of the write-up Justin has prepared as a "formal" response >> to the problems with authentication using OAuth and, as a second topic, >> potential re-chartering of the OAuth working group to work on some >> solutions in this area. Hannes suggested to postpone these discussions >> and to first finish the write-up Justin had distributed. >> >> Ciao >> Hannes & Derek >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
