I think you may be confusing Client credentials flow with resource owner credentials flow.
If there is a resource owner in the flow use code. The resource owner credentials flow is a bad idea and only put in for backwards compatibility. John B. > On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > > Hi All > > I've alway been thinking of Client Credentials as being the simplest flow but > now that I'm looking at implementing it myself to be used in the real > productions, I'm realizing that there's something I do not understand about > it: > > Do the clients using Client Credentials flow need to be OAuth2-registered, > even when such clients are already known to the authentication system ? > > For example, there might be some LDAP/etc entry for Alice (name, password). > Now a client is using a client credentials flow to get an access token: > > POST /token HTTP/1.1 > Host: server.example.com > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > Content-Type: application/x-www-form-urlencoded > > grant_type=client_credentials > > I hope that in this case no explicit registration (the one typically required > in redirection based flows) is needed, the client (Alice) has been > 'implicitly' registered (as far as the notion of OAuth2 client is concerned) > in LDAP/etc. > > If the explicit registration with OAuth2 AS was still required in the case > above then it would lead to a fairly massive duplication of effort (Alice is > registered in Ldap, then also with OAuth2 AS), etc > > Can someone clarify it please ? > > Thanks, Sergey > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
