Discover endpoints and interpret the result

A usable code is neither a client secret nor an authorization decision.

• Authorization-server metadata declares this grant by including urn:ietf:params:oauth:grant-type:device_code in grant_types_supported. device_authorization_endpoint is an OPTIONAL URL for the new endpoint (§4). The existing token endpoint is separate. Metadata examples assume a correctly configured trusted issuer; this is not an issuer discovery or trust-validation tutorial.
• The device authorization response’s expires_in is REQUIRED for code lifetime. The later token success response requires access_token and token_type; its expires_in is RECOMMENDED and refresh_token OPTIONAL. scope must be returned if different from that requested. Responses containing tokens/credentials/sensitive information MUST have Cache-Control: no-store and Pragma: no-cache (RFC6749§5.1).
• An access token is the credential for protected-resource access under its token type and scope. The human user code only identifies an authorization session. Token validation and permission enforcement by the resource service are separate from user-code entry; no successful resource request is implied by merely having a code (§1; RFC6749§§5.1,7).
• §6 is explicitly non-normative usability discussion. Its example eight-character base20 alphabet avoids vowels; dashes improve readability. The example WDJB-MJHT has20^8 possibilities before formatting, while the nine-digit example019-450-730 has10^9. These are examples, not mandated alphabets, lengths, entropy guarantees or rate-limit settings.
• For these suggested code formats the server should remove formatting and normalize case as applicable. The final picture uses that limited normalization example; matching normalized text alone does not authorize a device. Visual display is not universally required: alternative one-way channels are possible (§5.7); the MUST still display user_code applies specifically to the complete-URI optimization (§3.3.1).
• Clients and servers MAY negotiate additional interaction methods, but alternatives to the verification-URI interaction are outside this specification (§6.2). Device flow is for constrained input/browsers, not a blanket replacement for the external-browser native-app approach (§1). Use the linked OAuth security guidance when implementing a deployment.