Client registration is so that (1) the authorization server can obtain the client type (confidential or public), then, (2) if appropriate, obtain the client's Redirection Endpoint URI, so that the authorization server's authorization endpoint can avoid needing to be an open redirector, and (3) to obtain any metadata that the authorization server will display to the resource owner just prior to them approving or denying the authorization request. The spec explains this [1].
Also, service providers who are custodians of the resource owners' data want you to be accountable to them and their users, so they want to have some information about you.
There's a proposed standard for dynamic (and/or programmatic) client registration [2]. While there are some interesting use-cases, it offers little benefit to a service provider who wants to vet clients (or appear as if it did).
The spec contains some design recipes if you want a loose association between which clients are allowed to receive data the user approved (i.e. implicit grant), if you care little about whether the user trusts your app (i.e. resource owner password credentials grant), or if you care little about user approval (i.e. client credentials grant). The catch is that your unilateral opinions are insufficient: the client and service provider need to be in agreement about whether these are okay to use.
And, as is often the case with "kitchen sink"-type specs, these other usage modes muddy the waters around the safer and saner usage modes, so much of the current advice on OAuth2 focuses on dissuading their use.
Also, service providers who are custodians of the resource owners' data want you to be accountable to them and their users, so they want to have some information about you.
There's a proposed standard for dynamic (and/or programmatic) client registration [2]. While there are some interesting use-cases, it offers little benefit to a service provider who wants to vet clients (or appear as if it did).
The spec contains some design recipes if you want a loose association between which clients are allowed to receive data the user approved (i.e. implicit grant), if you care little about whether the user trusts your app (i.e. resource owner password credentials grant), or if you care little about user approval (i.e. client credentials grant). The catch is that your unilateral opinions are insufficient: the client and service provider need to be in agreement about whether these are okay to use.
And, as is often the case with "kitchen sink"-type specs, these other usage modes muddy the waters around the safer and saner usage modes, so much of the current advice on OAuth2 focuses on dissuading their use.
[1] https://tools.ietf.org/html/rfc6749#section-2 [2] https://tools.ietf.org/html/rfc7591