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
