The redirect URI needs to point to a location where your application can receive HTTP requests (e.g. a local temporary web server if your application is running locally).
The server will redirect clients to make a HTTP request to that registered redirect URL. That HTTP request contains the authorization code that you can then use to request access tokens from the authorization server.
All of this is specified in the corresponding RFC (~= internet standard document) RFC 6749 - The OAuth 2.0 Authorization Framework
Section 3.1.2.x describes the redirect URI, but it pretty much says that it’s just a normal URL.
Section 4.1 is particularly relevant here and describes the overall authorization flow.
4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.
+----------+
| Resource |
| Owner |
| |
+----------+
^
|
(B)
+----|-----+ Client Identifier +---------------+
| -+----(A)-- & Redirection URI ---->| |
| User- | | Authorization |
| Agent -+----(B)-- User authenticates --->| Server |
| | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Authorization Code ---------' |
| Client | & Redirection URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
two parts as they pass through the user-agent.
Figure 3: Authorization Code Flow
The flow illustrated in Figure 3 includes the following steps:
(A) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.
(D) The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.
(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.
Section 4.1.2 describes the HTTP request to the redirect URL that will be made.
RFC8252 is also relevant here since it describes common methods on how to use Oauth 2.0 for native apps/scripts (i.e. not hosted web-services). See section 7.
Redirection to a local URI is what e.g. JOSM is doing for example.
The URI urn:ietf:wg:oauth:2.0:oob is not specified by the standard, but has become a de-facto standard URI to indicate that the autorization code should not be passed via the redirect URL request, but handed to the user out-of-band (hence the oob at the end), i.e. displayed directly in the browser after authentication. The user can then copy the displayed authorization code and pass it to their app/script manually.
It’s technically allowed by the standard, but I don’t think OSM implements it. The purpose is to allow the client to choose between different redirect URLs.
All that being said, just look up a guide on how to use / implement Oauth 2.0. The standard documents are not really written in a way that is helpful if you just want to know how to use it.