Authlib

General Information

Field	Value
Package Name	Authlib
Manufacturer / Vendor	Hsiaoming Yang (Lepture) / authlib-team and contributors
Software Category	Library
Primary Documentation	Documentation, GitHub, PyPI
Programming Language(s)	Python
License	BSD-3-Clause License
Deployed Version(s)	>=1.6.4 (version-locked at 1.6.6)
Most Recent Available Version	1.6.6
Last Review Date	2026-01-27

Overview

Authlib is the ultimate Python library for building OAuth and OpenID Connect clients and servers. It implements comprehensive OAuth 1.0 and OAuth 2.0 support, along with OpenID Connect functionality, and includes JSON Web Token (JWT) and related cryptographic standards (JWS, JWK, JWE, JWA). The library provides integrations with popular Python frameworks including Flask, Django, FastAPI, and Starlette.

Within the medical device software, Authlib is used exclusively in the API Gateway service for stateless user authentication via JSON Web Tokens (JWT). The library's authlib.jose module is integrated into the authentication infrastructure to provide:

• JWT token generation: Creating secure access tokens for authenticated user sessions using HMAC-SHA256 symmetric key signing via the jwt.encode() function
• JWT token validation: Verifying token signatures and validating claims (subject, issued-at, expiration) during protected endpoint access via the jwt.decode() function
• Token error handling: The JoseError exception class provides structured error handling for invalid, expired, or malformed tokens

The authentication system protects all clinical endpoints (diagnosis-support, severity-assessment) and internal monitoring endpoints. The implementation follows the OAuth2 Password Grant pattern for the login flow, returning standard token responses with access_token, token_type, and expires_in fields.

Authlib was selected over alternatives (PyJWT, python-jose) due to:

• Comprehensive JOSE (JSON Object Signing and Encryption) implementation with active maintenance
• Well-documented API with clear security guidance
• Strong compatibility with FastAPI and Starlette frameworks used by the device
• BSD-3-Clause license permitting commercial use in medical device software
• Active community support and security response process
• Minimal dependency footprint (only requires cryptography package)

Functional Requirements

The following functional capabilities of this SOUP are relied upon by the medical device software.

Requirement ID	Description	Source / Reference
FR-001	Encode JWT tokens with header, payload, and HMAC signature	authlib.jose.jwt.encode()
FR-002	Decode and verify JWT token signatures using symmetric keys	authlib.jose.jwt.decode()
FR-003	Validate JWT claims including expiration time	claims.validate() method
FR-004	Provide structured exception handling for token validation failures	authlib.jose.JoseError
FR-005	Support HMAC-SHA256 (HS256), HMAC-SHA384 (HS384), and HMAC-SHA512 (HS512) algorithms	JOSE specification support

Performance Requirements

The following performance expectations are relevant to the medical device software.

Requirement ID	Description	Acceptance Criteria
PR-001	Token generation shall complete within acceptable API latency bounds	Token generation completes within the overall request timeout
PR-002	Token validation shall not introduce significant endpoint latency	Token validation overhead < 10ms per request
PR-003	Memory usage shall remain constant during repeated token operations	No memory leaks during sustained authentication workloads

Hardware Requirements

The following hardware dependencies or constraints are imposed by this SOUP component.

Requirement ID	Description	Notes / Limitations
HR-001	x86-64 or ARM64 processor architecture	Pre-built wheels available for common platforms
HR-002	Sufficient system memory for cryptographic operations	Minimal memory footprint (< 50MB)

Software Requirements

The following software dependencies and environmental assumptions are required by this SOUP component.

Requirement ID	Description	Dependency / Version Constraints
SR-001	Python runtime environment	Python >=3.9
SR-002	Cryptography library for cryptographic primitives	cryptography package (bundled dependency)
SR-003	Secure storage for JWT secret key	File-based secret key (not environment variable)

Known Anomalies Assessment

This section evaluates publicly reported issues, defects, or security vulnerabilities associated with this SOUP component and their relevance to the medical device software.

Anomaly Reference	Status	Applicable	Rationale	Reviewed At
CVE-2024-37568 (Algorithm Confusion)	Fixed	No	Critical algorithm confusion vulnerability affecting JWT decoding with asymmetric keys; fixed in version 1.3.1. The device uses version 1.6.6 which includes the fix. Additionally, the device exclusively uses HMAC symmetric key algorithms (HS256), not asymmetric keys, eliminating the attack vector	2026-01-27

Authlib is actively maintained by the authlib-team with a responsible security response process. The project uses GitHub Security Advisories for coordinated disclosure. According to the NVD and Snyk vulnerability database, the deployed version (1.6.6) includes fixes for all known security vulnerabilities.

The device's usage pattern minimizes attack surface exposure:

• HMAC-only algorithms: The device exclusively uses symmetric HMAC algorithms (HS256, HS384, HS512), not asymmetric algorithms (RS256, ES256). This eliminates the attack vector for CVE-2024-37568 which specifically targets algorithm confusion between asymmetric and symmetric key verification
• No OAuth endpoint exposure: The device does not expose OAuth authorization endpoints; Authlib is used solely for JWT token operations within the internal authentication flow
• No external identity provider integration: All authentication is handled internally; no third-party identity providers or external OAuth flows are configured
• Secret key file storage: JWT secret keys are loaded from secure file storage during application bootstrap, not from environment variables or hardcoded values
• Token validation at gateway: All token validation occurs at the API Gateway boundary before requests reach clinical processing endpoints
• Stateless authentication: No server-side session storage; tokens are self-contained and validated on each request

Risk Control Measures

The following risk control measures are implemented to mitigate potential security and operational risks associated with this SOUP component:

• Version locking via requirements_lock.txt ensures reproducible, auditable deployments with known-secure versions
• JWT secret keys are stored securely in files with restricted filesystem permissions
• Token expiration is enforced (default 1 hour) limiting the window for token abuse
• Failed login attempt tracking and account lockout prevent brute-force attacks
• Comprehensive unit and integration test coverage validates token generation and validation behavior
• Exclusive use of HMAC symmetric algorithms eliminates algorithm confusion attack vectors

Assessment Methodology

The following methodology was used to identify and assess known anomalies:

• Sources consulted:

  • National Vulnerability Database (NVD) search for "authlib"
  • GitHub Security Advisories for authlib/authlib
  • Snyk vulnerability database for package security analysis
  • PyPI package security reports
  • CVE Details and security research publications

• Criteria for determining applicability:

  • Vulnerability must affect deployed version (1.6.6)
  • Vulnerability must be exploitable in the device's JWT authentication context
  • Attack vector must be reachable through the device's interfaces (no external OAuth flows, no asymmetric key operations)
  • The device's exclusive use of HMAC algorithms must not mitigate the vulnerability

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001