Okta
By default, GovEagle uses Okta to manage authentication. Unlike a company-managed login, GovEagle's Okta org is a dedicated identity system for GovEagle users. Here's what that means for you:
Independent Accounts – User identities are stored in GovEagle's Okta org, not in your company's identity provider.
Security Built-In – Okta issues secure OAuth 2.0 / OpenID Connect tokens after login, ensuring encrypted, standards-based authentication. MFA and session policies are enforced in the Okta org.
Flexible Identity Options – While today GovEagle accounts are provisioned directly (via Admin invitation), Okta allows us to support advanced login methods as well. See SSO Configuration below.
Note for IT teams: authentication is served from goveagle.okta.com. If your organization filters outbound traffic, see Whitelisting Domains for GovEagle Applications and Services.
Role Based Access Control (RBAC)
GovEagle uses role-based access control (RBAC) to determine what each user can do after authentication through Okta. Roles are assigned by your workspace Admin and enforced directly in GovEagle.
For more details about creating and assigning user roles, see Managing Users & Access Control.
SSO Configuration
GovEagle is built on Okta, which supports federation with external identity providers. This means your organization can configure Single Sign-On (SSO) so users can log in with their existing corporate credentials (e.g., Microsoft Entra ID, Ping, or another SAML/OIDC provider).
How SSO Works in GovEagle
Your identity provider (IdP) authenticates the user.
Okta federates with that IdP and issues a secure OIDC / OAuth 2.0 token.
GovEagle consumes that token and applies the appropriate role-based permissions (User or Admin).
Steps to Set Up SSO
Contact GovEagle Support – Provide details of your identity provider (e.g., SAML vs. OIDC, IdP metadata URL).
GovEagle Setup – Our team will supply the required configuration values:
Redirect URI
Client/Application ID
Requested claim mappings (e.g.,
email,name)Token requirements (ID token issued via OIDC / SAML assertion)
IdP Configuration – Your IT team adds GovEagle as an application in your IdP and maps attributes appropriately.
Testing – Work with GovEagle Support to validate authentication flows in a staging or sandbox environment.
Enable for All Users – Once verified, the "Sign in with [Your Company]" button will appear on the GovEagle login page.
Expectations When Configuring SSO
Timeline: Most SSO setups take 2-3 weeks, depending on your IdP complexity and IT team's responsiveness.
Responsibility Split:
GovEagle provides metadata, configuration guidance, and testing support.
Your IT team is responsible for configuring the application in your IdP and ensuring claims are mapped correctly.
Customization: We support both OIDC and SAML federation. If your organization has special requirements (custom claims, multiple IdPs, conditional access policies), let GovEagle Support know in advance.
User Experience: Once live, users will click "Sign in with [Your Company]" instead of creating a separate GovEagle password.
FAQ
Q: How is GovEagle's Okta org different from my company's identity provider?
A: Your company's identity provider (for example Microsoft Entra ID inside your Microsoft 365 tenant) governs access to your own internal applications. GovEagle's Okta org is a separate identity system that GovEagle manages for the GovEagle application, and it issues authentication tokens using OAuth 2.0 / OIDC standards. The two can be connected — see SSO Configuration above.
Q: Can GovEagle support single sign-on (SSO) with my organization's identity provider?
A: Yes, take a look at SSO Configuration above.
Q: Why don't I log in with my company's Microsoft account?
A: By default, GovEagle accounts are created in our Okta org. This ensures consistent identity management across all customers and avoids dependency on individual customer IT environments. While your account uses your work email address, it is not linked to your company's identity provider unless you configure SSO.