On Oct 17, 2014, at 10:57 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote:
> Hi, > On 17/10/14 15:09, Richer, Justin P. wrote: >>>>> - 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). >>>> >>> Yes, it is not part of OIDC but it is still the authentication of the >>> client that is effectively a resource owner, no human user is involved but >>> IMHO it's still very much the authentication. Exactly what the coded >>> clients do today in non OAuth2 client-server communications, except that in >>> this case the name/password is offered only once to AS. >>> May be it was not what this flow was envisaged for originally but I do like >>> it for the reasons outlined above, specifically it can help the >>> legacy/traditional clients to 'join' the OAuth2 AS infrastructure >> >> But it's not authentication of the *user*, which is the whole point. When >> the client authenticates on its own behalf, you have no idea who the user is >> or if they exist. It's irrelevant to the user authentication flow. If you're >> looking for pulling legacy clients in, the "password" flow is better for >> that, but OIDC didn't profile it because people really shouldn't be using >> the password flow except in very limited use cases in the first place. > > I did get that. See the notes are about "OAuth2 & Authentication", so I > thought it would not only be about the human user being authenticated via > OIDC. > OAuth2 has different flows with some of them requiring no human user being > around, and the client_credentials flow is all about authenticating the > client giving the token back for it to access its own resources, except that > not having to sent name/password every time. > This client does not need to be aware of any users because effectively this > client is a 'user'. > If "OAuth2 & Authentication" implies the human user is involved then may be > it would be clearer if the subject was reworded somehow... > Either way, if you reckon the client-credentials are out of scope then I'm > fine with that, I guess keeping it focused on OIDC will help with the message Interesting, that's a misinterpretation that I didn't anticipate. I think I'm going to rename the whole page "OAuth and User Authentication" to avoid that. > >> >>> >>>>> - 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. >>> OIDC RP is a client. But this RP doe snot have to be collocated with the >>> OAuth2 client which actually does some application specific work, right ? >>> I.e OIDC RP facilitates the OAuth2-based authentication mechanism but the >>> server 'protected' by this RP which would work with the authenticated user >>> does not have to be OAuth2 client, do you agree ? >>> If OIDC RP could only be used alongside OAuth2 clients then it would limit >>> its usefulness IMHO >> >> >> But the OIDC RP *is* an OAuth Client, so I still don't get what you're >> saying. Sure you can have OAuth clients that *aren't* OIDC clients, but you >> can't have an OIDC client that isn't also an OAuth client because OIDC is >> built directly on top of OAuth. > > May be it is my language issues. I haven't suggested that OIDC can be > implemented without it being OAuth2 client. > > Consider this: > > OIDC RP filter <-> non OAuth2 server > > OIDC RP filter would do the OIDC thing (will act as OAuth2 client, return the > user to OIDC IDP, validate the response) and then set the security context > and let the user go to the non OAuth2 (client) server, with this server not > being even aware that the OIDC flow has happened. > > Am not making sense at all with the above ? I think I see what you're saying now -- you could have a client that authenticates the user through OIDC and also accesses some set of non-identity APIs through OAuth, and the two parts don't actually have to talk to each other. That's fine, but it's such a deep implementation detail that I don't think it helps the conversation that we're trying to have. Especially considering that the real problem stems from developers who do both authentication and authorized API access right side by side in the same code and get the two confused with each other. Is that a bit more clear? Thanks for your input, -- Justin > > Thanks, Sergey > > > >> >> -- Justin >> >> >> >>> >>> Cheers, Sergey >>> >>> >>>> >>>> -- 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
