Device Authorization Flow for a Rust CLI and an Axum API

Summary

Command-line tools lack browser redirect capabilities, preventing standard OAuth login flows. To resolve this limitation, the OAuth 2.0 Device Authorization Flow issues a temporary device code, presents a verification URL to the user, and waits for authentication in an external browser. A Rust workspace demonstrates this end-to-end pattern across a CLI, an Axum web API, and a shared authentication library. The shared library relies on jsonwebtoken and reqwest to fetch JSON Web Key Sets and validate token signatures, issuers, and audiences against typed claims. Axum secures protected routes through custom FromRequestParts extractors that decode Bearer headers, enabling verified CLI access.

Takeaways

1. 1

   Auth0 disables the Device Authorization grant type by default on Native Applications, causing token polling to fail with an unauthorized_client error if not explicitly enabled.

2. 2

   The shared Rust library validates RS256 JWT tokens by parsing the key ID from the header, retrieving matching public keys from Auth0's JWKS endpoint, and enforcing audience and issuer checks.

3. 3

   Axum route protection is implemented via the FromRequestParts trait, which extracts Bearer tokens from authorization headers and returns UNAUTHORIZED errors when validation fails.