OAuth Security

This page tells which security controls eCourtDate applies to SSO sign-ins, and which controls the agency sets at the identity provider.

Controls in eCourtDate

Control	Detail
Sign-in state	Each sign-in gets a random state value. eCourtDate accepts the return at the Redirect URL only with this value, and only one time. This blocks cross-site request forgery (CSRF) on the sign-in.
Agency app time limit	An Agency app sign-in must return to the Redirect URL within 5 minutes.
Console session binding	The Console keeps the state and the nonce in the browser session. A sign-in that starts in one browser cannot finish in a different browser.
ID token in the Agency app	The eCourtDate API gets the ID token directly from the Token URL over HTTPS. It authenticates with the Client ID and the Client Secret.
ID token checks in the Console	The Console verifies the signature, the issuer, the audience, the time, and the nonce of each ID token. See ID Token Checks in the Console.
Console access	The Console signs in only users who already exist and have Console access. The Console does not create users.
eCourtDate staff and partner accounts	These accounts cannot sign in through the identity provider of an agency. They use the standard eCourtDate sign-in.
IDP profile access	Only a Super Admin of the Default Agency of a profile can open, change, or delete the profile.
Client Secret	eCourtDate sends the Client Secret to the Token URL only.

Requirements for the Identity Provider

Requirement	Detail
HTTPS	All URLs of the provider use HTTPS.
Tenant-specific URLs	Use the URLs of the tenant or the organization. Do not use multi-tenant URLs, such as Microsoft common URLs.
Signed ID tokens	Sign ID tokens with RS256. Publish the keys at the jwks_uri in the discovery document.
Web client with a client secret	Register a web application client. eCourtDate sends the client secret with HTTP Basic authentication (client_secret_basic).
email claim	The ID token contains the email address of the user.

Multi-Factor Authentication

eCourtDate does not ask SSO users for multi-factor authentication (MFA). The identity provider asks for MFA before it sends the user back to eCourtDate. Set the MFA rules at the identity provider for all users who can sign in to eCourtDate.

The MFA methods depend on the identity provider. Examples are:

• FIDO2 and WebAuthn security keys
• PIV and CAC smart cards
• Authenticator apps with time-based codes
• Push notifications

FedRAMP

eCourtDate works with each OpenID Connect provider that meets the requirements for other OpenID Connect providers. For FedRAMP requirements, find the current authorization of the identity provider in the FedRAMP Marketplace.

Best Practices

• Separate staging and production. Register one client for the staging profile and a different client for the production profile. Each client has its own Client Secret.
• Turn on user assignment. At the identity provider, let only assigned users and groups sign in to the client.
• Limit the Enabled Agencies. Select only the agencies that the users of the profile need.
• Use groups for agency access. Name the groups in the Group Name Format, so that each user gets only the agencies of the groups of that user.
• Control Super Admin. Use security, admin, or root as a standalone word in a role name only when the role is for Super Admins. See Super Admin.
• Change the client secret on time. Write down the expiry date of each client secret. Create a new secret before the old one expires.
• Add Alert Contacts. Enter the email addresses that get a notice when the monthly credentials test fails.
• Keep secrets private. Send the Client Secret only through a secure channel. Do not put it in a support ticket, an email, a log, or source code.
• Remove access when a user leaves. Disable the user at the identity provider. Also remove the user from the agencies in eCourtDate, because a sign-in never removes agencies.

Production Checklist

Before users sign in to production, make sure that each item is true:

• The production IDP profile has the production region, not staging.
• The production profile uses its own client at the identity provider, not the staging client.
• The identity provider has the Redirect URL of the production profile.
• The identity provider has the Console Redirect URL of the profile that Console users sign in with.
• The client is a web application with a client secret and HTTP Basic authentication.
• All provider URLs are tenant-specific and use HTTPS.
• The OIDC Configuration Check shows no errors and no warnings.
• The identity provider asks for MFA.
• User assignment is on at the identity provider.
• The Enabled Agencies contain only the necessary agencies.
• The IDP Last Sign In panel shows the correct email, groups, and roles claims for a test user.
• No role name gives Super Admin unless the role is for Super Admins.
• Alert Contacts has at least one email address, and the expiry date of the client secret is recorded.
• The End Session URL is set.
• A test sign-in is successful in the Agency app and in the Console.