Authentication Overview

Authentication is how eCourtDate verifies who is making a request. Before any system or user can access eCourtDate data, they must prove their identity. This prevents unauthorized access to the agency's information.

eCourtDate supports two authentication methods depending on the integration scenario: API Keys for server-to-server communication and OAuth / SSO for user-facing applications. This page compares them so the right approach can be chosen for the use case.

Which method should I choose?

• Connecting a backend system, script, or scheduled job? Use API Keys. They are designed for automated, server-to-server communication with no user interaction.
• Want users to log in with their existing work accounts (Microsoft, Google, Okta)? Use OAuth / SSO. It lets individual users authenticate through the organization's identity provider.

Method 1: API Keys (Client Credentials)

API keys use the OAuth 2.0 client_credentials grant to obtain a bearer token. This method is designed for backend services, cron jobs, data pipelines, and any integration where a server communicates directly with the eCourtDate API without end-user interaction.

How it works:

1. Create an API key in the eCourtDate Console under APIs (console.ecourtdate.com/apis).
2. Exchange the client_id and client_secret for an access token by sending a POST request to /oauth/token with grant_type set to client_credentials.
3. Include the access token in the Authorization: Bearer <token> header on every API request.
4. Tokens expire after a set duration. The integration should request a new token before or when the current one expires.

Best for: automated integrations, backend services, scheduled data syncs, server-to-server communication.

For full details and code examples, see the API Authentication guide.

Method 2: OAuth / SSO (Authorization Code)

OAuth / SSO uses OpenID Connect with the OAuth 2.0 Authorization Code flow. Users sign in to the eCourtDate Agency app and the eCourtDate Console with their account at the identity provider of their organization.

Supported identity providers:

• Microsoft Entra ID (Azure AD)
• Google Workspace
• Okta
• AWS Cognito
• Other OpenID Connect providers that meet the requirements

How it works:

1. A Super Admin creates an IDP profile under IDPs in the eCourtDate Console.
2. The user opens the Sign-in URL of the profile, and eCourtDate sends the browser to the identity provider.
3. The user signs in at the identity provider, which sends an authorization code back to eCourtDate.
4. eCourtDate sends the code to the token endpoint of the provider and reads the ID token.
5. eCourtDate finds the user by email, applies the agencies and roles, and starts an eCourtDate session.

Best for: agency staff who sign in to the Agency app or the Console with their organization account.

For configuration instructions and provider-specific setup guides, see the OAuth / SSO documentation.

Comparison

	API Keys (Client Credentials)	OAuth / SSO (Authorization Code)
Flow	client_credentials grant	Authorization Code grant
User interaction	None: fully automated	User signs in via identity provider
Managed in	Console > APIs	Console > IDPs
Credential type	Client ID + Client Secret	Client ID + Client Secret of the identity provider client, with the Redirect URL
Use case	Server-to-server, batch jobs, data pipelines	Staff sign-in to the Agency app and the Console
Token represents	The API key / application	An individual user session

Next Steps

• Quickstart: See API key authentication in action with a step-by-step example.
• API Authentication: Detailed guide for API key setup, token management, and error handling.
• OAuth / SSO: Full configuration guide for single sign-on with supported identity providers.