What must a client provide when it registers with an OAuth service, and what does it receive in return?

It registers at least an application name, a website and a redirect URI (callback URL); in return it receives a public client ID and, for confidential clients, a secret client secret.

Provided by the application:

• Application name and application website: shown to users on the consent screen, so they know who is asking.
• Redirect URI / callback URL: where the authorization server sends the user back after authentication. This endpoint of the application must handle the returned code or tokens.

Issued by the service (often after the application has passed some checks):

• Client identifier (client ID, app ID): a unique public name by which the service recognises the application. It appears in URLs and is not a secret.
• Client secret: used to authenticate the application, typically a long random hex string. It must be kept secret, which is only possible for confidential clients.

The registration is what makes step ④ of the flow possible: when the client later presents its ID and secret, the authorization server compares them with what it issued, and it will only send codes to the redirect URIs registered for that client ID.

Go deeper:

• RFC 6749, Section 2: Client Registration — client identifiers, redirect URIs and client authentication.
• RFC 7591: Dynamic Client Registration — how clients can register automatically through an API instead of a web form.