>>> - 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. > >>> - 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. -- 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
