Are you saying that the OIDC filter/client can set session cookies in a domain that other web servers can use, so they don't have to have any direct knowledge of Connect.
I suspect that is a common practice in many SSO implementations. It is true that not every web server needs to implement connect itself for SSO. John B. On Oct 17, 2014, at 11: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 > >> >>> >>>>> - 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 ? > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
