Skip to content

Current Status

Jump to bottom
Mehrnoush edited this page Oct 25, 2024 · 1 revision

RustifyAuth is progressing well towards a secure and flexible OAuth 2.0 and OAuth 2.1-compliant authentication and authorization system. Here’s a quick summary of the current project status and a focus on dynamic client registration implementation as per RFC 7591.

Architecture & Key Components

  • Modular Design: Organized components such as Authentication, Token Management, and Authorization, with a modular structure.
  • Token Management: Supports access and refresh tokens, rotation, and revocation.
  • PKCE and JWT Handling: PKCE for public clients and JWT support with multiple signing algorithms (RSA, ECC, etc.).

Security Features

  • RBAC with Token Binding: Implemented role-based access control and token binding during client registration.
  • Rate Limiting and Error Handling: Basic rate limiting is in place with comprehensive error handling for easier troubleshooting.
  • Advanced Refresh Token Rotation: Fully implemented, enhancing security by rotating tokens on each use.

OAuth2 Flows & RFCs

  • Supported Flows: Authorization Code, Client Credentials, Device Authorization.
  • Token Introspection & Revocation: Implemented introspection and revocation endpoints as per RFC 7009 and RFC 7662.
  • OAuth2.1 Compliance: Ongoing improvements, with PKCE implemented and secure defaults enforced.

Dynamic Client Registration (RFC 7591)

  • Implemented /register endpoint to allow clients to dynamically register.
  • Includes client_name, redirect_uris, grant_types, and response_types fields.
  • Supports client metadata validation, such as the requirement of redirect_uris.

RFC 7591 - Dynamic Client Registration Details

1. Dynamic Client Registration Endpoint

Endpoint: /register Method: POST Headers: Requires Authorization and optionally X-Token-Binding. Functionality: Allows new clients to register themselves with essential metadata. Validates input fields to ensure compliance (e.g., non-empty redirect_uris). Returns a unique client_id and client_secret upon successful registration.

2. Fields and Parameters

Client Metadata: client_name: Identifies the client. redirect_uris: Required, must contain at least one URI for redirects. grant_types: Defines supported OAuth flows (e.g., authorization_code, client_credentials). response_types: Expected responses (e.g., code, token). software_statement: Optional JWT or metadata, allowing verification of client details.

ClientStore and Token Binding

  • Client Metadata Storage: Registered clients and their secrets are stored within ClientStore, supporting both in-memory and Redis backends.
  • Token Binding: Associates tbid (Token Binding ID) with clients, enhancing session security by tying tokens to specific sessions.

Testing and Enhancements for Dynamic Client Registration

Tests

  • Client Registration: Successfully verifies registration with expected metadata.
  • TBID Binding: Tests confirm tbid extraction and storage with each client.
  • Error Scenarios: Tests cover unauthorized access, invalid metadata, and empty fields.

Clone this wiki locally