How does OpenID Connect Discovery let a client find an OpenID Provider's endpoints and keys?

The OP publishes a JSON configuration document at <issuer>/.well-known/openid-configuration listing its issuer identifier, endpoints (authorization, token, UserInfo), the location of its signing keys (jwks_uri) and supported features; the client reads it instead of hard-coding them.

Without discovery, every RP would need a hand-maintained list of the provider's URLs and keys, which breaks when the provider changes anything. With discovery, the RP only needs the issuer URL, then fetches for example https://accounts.google.com/.well-known/openid-configuration and gets:

• issuer: the exact value the ID token's iss claim must have.
• authorization_endpoint, token_endpoint, userinfo_endpoint (and often end_session_endpoint for logout).
• jwks_uri: where the OP publishes its public keys (a JSON Web Key Set) for verifying ID token signatures. Keys can be rotated without RPs changing configuration.
• Capabilities: response_types_supported, scopes_supported, id_token_signing_alg_values_supported, claims_supported.

Discovery also has an optional first step: finding which issuer is responsible for a user (from an identifier such as an email address) via WebFinger.

Go deeper:

• OpenID Connect Discovery 1.0: Provider Metadata — every field of the configuration document.
• Google's live discovery document — a real OP configuration to read through.