oauth-device-flows 0.1.0

A specialized Rust library implementing OAuth 2.0 Device Authorization Grant (RFC 8628)
Documentation
<!-- Use this file to provide workspace-specific custom instructions to Copilot. For more details, visit https://code.visualstudio.com/docs/copilot/copilot-customization#_use-a-githubcopilotinstructionsmd-file -->


# OAuth Device Flows Crate - Copilot Instructions


This is a specialized Rust library that implements the OAuth 2.0 Device Authorization Grant (RFC 8628). When working on this codebase, please follow these guidelines:

## Code Style and Patterns

- Follow Rust idioms and best practices
- Use `thiserror` for error handling
- Prefer `secrecy::Secret` for sensitive data like tokens and client secrets
- Use `time` crate for timestamp handling instead of `chrono`
- Async/await pattern throughout for HTTP operations
- Builder pattern for configuration objects

## Architecture

- **Provider-agnostic design**: Support multiple OAuth providers (Microsoft, Google, GitHub, GitLab, Generic)
- **Strong typing**: Use dedicated types for requests/responses instead of generic hashmaps
- **Error handling**: Comprehensive error types that distinguish between different failure modes
- **Security**: Secure handling of tokens and secrets using the `secrecy` crate
- **Extensibility**: Easy to add new OAuth providers

## Key Components

1. **DeviceFlow**: Main orchestrator for the device authorization flow
2. **DeviceFlowConfig**: Configuration builder with sensible defaults
3. **TokenManager**: Handles token refresh and lifecycle management
4. **Provider**: Enum and configurations for different OAuth providers
5. **Types**: Strong typing for all OAuth request/response structures

## Testing Approach

- Use `wiremock` for mocking OAuth endpoints in tests
- Test error conditions thoroughly (expired tokens, denied auth, network errors)
- Include integration tests for each supported provider
- Test token refresh scenarios

## Dependencies Philosophy

- Minimal dependencies for embedded/WASM compatibility
- `reqwest` with rustls for HTTP (no OpenSSL dependency)
- Optional features for non-essential functionality (like QR codes)
- Prefer widely-used, well-maintained crates

## Security Considerations

- Never log sensitive information (tokens, client secrets)
- Use secure defaults (rustls over OpenSSL)
- Validate all inputs from OAuth servers
- Implement proper timeout handling for HTTP requests

## Documentation

- Comprehensive doc comments with examples
- Error conditions clearly documented
- Provider-specific quirks and requirements noted
- Real-world usage patterns in examples