Oh man, I've done Google, Facebook, Reddit and all of them have tiny but annoying differences in their Auth Flow. I've given up up on Twitter, because they didn't even seem to support OAuth2 (maybe they do now?), but it was too much of a pain.
What's also very annoying is the need to register an "application" at the provider. So i.e. for Facebook you have to login into their developer portal, create an app, fill out all the stuff they want to know, and then rely on them to approve your app. You have to do this for each and every provider, and for each application you want to support, and of course they all have different developer portals and want to know varying amounts of information... I've given up on Instagram OAuth because it seemed to much hassle to get your application approved.
Don't know why this is necessary, there should be a simple straightforward spec solely for Auth, that doesn't require all these steps.
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.
Technically unregistered clients are within spec. IndieAuth is one such implementation, focused on federated services. Aaron Parecki has a good writeup here[0]. Unfortunately that's not going to help you when playing with the big boys.
There's a spec for dynamic registration of clients for Oauth2/OIDC if I recall correctly. There's a reason that you have to register, and it's because you're potentially obtaining information about users, and they need a way to be able to block specific (potentially malicious) clients using their IDP.
When I was looking up the OAUTHBEARER draft, there's a (OPTIONAL) field in the error response to point to the openid-configuration for dynamic registration. At the time I was implementing things for Thunderbird, no one was using this yet, and I would be surprised if this has actually been implemented by any major provider in any sort of usable way for clients.
Yeah no one uses it because they explicitly want you to authenticate to register the clients on the users behalf so they can lock you out if you abuse it. It's annoying, but it makes sense. Otherwise an abuser can just dynamically create new clients anytime their existing clientID is banned.
Did you end up implementing it in Thunderbird?
We're looking to do that at my company and I'm currently implementing OAUTHBEARER in cyrus-sasl (which then could be used in cyrus-imapd & postfix)
I haven't implemented it myself, and as far as I'm aware, it hasn't been in the past few years. If it is going into cyrus-sasl, then I can probably put together containers for testing (which is on my work todo list anyways).
One particularly nasty annoyance I've discovered recently is SoundCloud, which describes in great detail how to use their API and how to register applications, except when you actually try to do that, you discover that they "temporarily" disabled application registration several years ago and never re-enabled it.
Ok so the other replies here clarify why — but really it'd have been nice if there was at least some consistent interface between all the OAuth / OIDC providers, so one wouldn't need to learn new interfaces all the time.
... And, worse, now I need to take screenshots and document all these different interfaces, for an open source project I'm building, whose users might want to register OIDC client apps too. :- /
What's also very annoying is the need to register an "application" at the provider. So i.e. for Facebook you have to login into their developer portal, create an app, fill out all the stuff they want to know, and then rely on them to approve your app. You have to do this for each and every provider, and for each application you want to support, and of course they all have different developer portals and want to know varying amounts of information... I've given up on Instagram OAuth because it seemed to much hassle to get your application approved.
Don't know why this is necessary, there should be a simple straightforward spec solely for Auth, that doesn't require all these steps.