Access Control
eCourtDate enforces layered access controls to ensure that only authorized users and systems can access agency data. This page covers authentication methods, multi-factor authentication, role-based permissions, and API access controls.
Authentication Methods
| Method | Use Case | Details |
|---|---|---|
| API Keys (client_id / client_secret) | Server-to-server API integration | OAuth 2.0 Client Credentials flow. See API Authentication. |
| OAuth / SSO | Console user login via identity provider | SAML/OIDC with Azure AD, Google, Okta, and others. See OAuth / SSO. |
| SSH Keys | SFTP file transfer authentication | Key-based authentication recommended. See SFTP Authentication. |
| Console Login | Direct Console access | Email and password with mandatory MFA. |
Multi-Factor Authentication
MFA is mandatory for all Console user accounts. eCourtDate supports multiple MFA methods:
- Authenticator apps: TOTP-based codes from apps such as Google Authenticator, Microsoft Authenticator, or Authy
- Hardware security keys: FIDO2/WebAuthn devices (YubiKey and similar)
- PIV/CAC smart cards: Personal Identity Verification and Common Access Card support for government users
- IDP-enforced MFA: When using SSO, MFA is enforced at the identity provider level. See OAuth Security for details.
Role-Based Permissions
eCourtDate uses granular, role-based access controls:
- CRUD permissions: Create, Read, Update, and Delete permissions are assigned per record type
- Agency-level assignment: Permissions are scoped to the agency, preventing cross-agency data access
- Administrative roles: Separate roles for agency administrators, standard users, and read-only users
For a detailed permission matrix showing all record types and permission levels, open a support ticket in the Console using the Help button in the bottom-right corner.
API Access Controls
API access is restricted through multiple mechanisms:
- Agency-scoped clients: Each API client is bound to a specific agency. Cross-agency access is not possible through a single client.
- IP allowlisting: API clients can be restricted to specific source IP addresses. Requests from unlisted IPs are rejected. See IP Allowlisting.
- Token expiration: OAuth 2.0 access tokens expire and must be refreshed. See Token Lifecycle.
- Separate credentials: Use separate API credentials for staging and production environments. See Environments.
Session Management
For details on Console session timeout policies and concurrent session limits, open a support ticket in the Console using the Help button in the bottom-right corner.
Principle of Least Privilege
Follow these guidelines to minimize unnecessary access:
- Separate API clients per integration: Create dedicated API credentials for each system that connects to eCourtDate
- Minimum permissions: Assign only the permissions each integration requires
- Periodic access review: Review user accounts and API clients regularly; revoke access that is no longer needed
- Rotate on personnel changes: When staff with access leave or change roles, rotate affected credentials. See Key Management.
Related Pages
- API Authentication: OAuth 2.0 Client Credentials flow
- OAuth Security: SSO security requirements and MFA enforcement
- Key Management: Credential management and rotation
- IP Allowlisting: Network-level access restrictions
- Audit Logging: Monitoring authentication events and access patterns