So long as you’re storing the client_id and client_secret in your LDAP and not putting a username and password (that normally represents a person) into the software, you’re fine. That’s just a case of externalizing the client registration to the LDAP system — it’s still registered.
Otherwise, if you’re putting a person’s information into the client there, you’re doing impersonation. That’s bad, don’t do that. — Justin > On Mar 15, 2016, at 9:17 AM, Sergey Beryozkin <sberyoz...@gmail.com> wrote: > > Hi Justin > > Many thanks for the quick response. > On 15/03/16 12:53, Justin Richer wrote: >> Is Alice the client here (the piece of software), or is Alice the >> resource owner? > Piece of software, something that needs to run without the human user being > involved >> If Alice is the resource owner, then you should >> absolutely not be using the client credentials flow like this. >> > Sure. > >> The client credentials flow is designed for cases where the client is >> acting on its own behalf, not on behalf of any particular user. It's an >> optimization of the canonical authorization code flow, where there is no >> interaction with the resource owner because there is no resource owner >> as a separate entity. It's most useful for backend systems that would >> have traditionally used a developer key to get access to bulk data. If >> you're using it for single-user access, you're doing it wrong. >> > I guess I'm still OK here, as I said, it is a piece of software which runs > without a user. Like in all web services (SOAP or plain HTTP client > invocations) where the client sets some credentials and accesses some data in > the remote service. > >> Also, you should keep in mind that things that seem "simple" on the >> surface are often simplified at the cost of making specific security >> concessions and assumptions. The authorization code flow is "complex" >> for very good reasons, all of them security focused. You should never >> pick a different OAuth flow just because it looks simpler, you should >> only pick them if you're within the use case that it was designed for, >> and therefor the assumptions of its security patterns match. >> > +1 >> We've seen a *ton* of problems with people picking the implicit flow in >> the real world and using it with clients other than in-browser >> applications that it was designed for. If you're not in that specific >> space, you're taking on huge risks. > Sure, I understand. > > So, as far as my original question is concerned, given that a client piece of > software (no human user is involved) uses some credentials to get the token > with client_credentials, would it be OK to avoid the explicit 'Client' > registration with AS, given that the authentication system employed by AS is > already aware of such credentials, I guess yes. > > Thanks, Sergey >> >> -- Justin >> >> On 3/15/2016 8:37 AM, Sergey Beryozkin 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 >> >> _______________________________________________ >> 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
