On this page
Sign users in overview
Okta provides authentication solutions that integrate seamlessly into your apps across a wide variety of platforms. You can develop an app for your employees or customers, build a portal for your partners, or create another solution that requires a sign-in flow. Our solutions are built on top of the OAuth 2.0 / OpenID Connect standard, and Okta also supports other options such as SAML.
Never used Okta before?
Choose your app type and get started with signing users in.
Already on Identity Engine and modernizing an existing flow?
If you've already upgraded to Okta Identity Engine, and you're updating an existing Classic Engine authentication implementation:
Choose your Identity Engine authentication modernization approach: A ranked decision guide for choosing between redirect, embedded widget, embedded SDK, and direct authentication.
Primary considerations
Each app that you add authentication to has slightly different requirements. But there are some primary considerations that you need to think about regardless of which app you’re dealing with.
| Authentication methods | Assurance levels | Policies | Deployment models |
|---|---|---|---|
| There are many different methods that you can choose to authenticate users, ranging from a simple challenge based on something they know like a password. Or use something more sophisticated involving a device that they own (like an SMS or call) or a personal attribute (like biometrics). | To guarantee that the user is who they say they are, you can combine different authentication methods for higher security requirements. | Create policies in your Okta org to govern who needs to authenticate with which methods, and in which apps. If you’re using Okta Identity Engine, you can create flexible apps where you can change their authentication methods without having to alter any code. See Configure a global session policy and app sign-in policies for basic information. Our use cases contain information on what policies are required for each. | Okta has multiple authentication solutions that provide trade-offs in terms of implementation complexity, maintenance, security, and degrees of customization. See Choose your auth. |
After reviewing the primary considerations, you can integrate Okta authentication with your app. Typically, you create an Okta org and an app integration to represent your app inside Okta, inside which you configure your policies. Then, connect your app to Okta using whatever mechanism makes sense for the deployment model that you choose.
Other considerations: There are several other things that you need to consider, such as whether to use Single Sign-On, to add an external identity provider, and more. See Next steps.
Choose your auth
| Okta-hosted Sign-In Widget | Embedded Sign-In Widget (Gen 2) | Embedded SDK-driven sign-in flow | Direct authentication | |
|---|---|---|---|---|
| Use a standards-based federation flow (SAML, OIDC, or OAuth) to delegate the entire sign-in experience to Okta. Okta hosts, maintains, and evolves the sign-in experience for you. This is the recommended approach because it's the most secure, easiest to maintain, and inherits new authenticator support automatically. | Embed the Okta Sign-In Widget (Gen2) into your own code base to host the authentication client on your servers. The third-generation (Gen3) widget is delivered as the Okta-hosted sign-in flow that's supported for self-hosted embedding. Embedding provides a balance between complexity and customization. | Use our SDKs to create a custom authentication experience. This option is the most complex and leaves you with the most responsibility, but offers the most control. | Use direct authentication for native, server-side, or machine-to-machine flows where a browser flow isn't possible. | |
| Effort |  |  |  | to |
| Maintenance | No updates required | Requires updating widget packages | Requires updating SDK packages and adapting to changes | |
| Security | The most secure option. No XSS attacks, Okta takes care of it all | Responsibility shared with Okta | Security is your responsibility | Security is your responsibility |
| Customization | Substantial managed customization options for domains, emails, sign-in page CSS, and brand-aligned page customization, all without taking on the maintenance and security burden of self-hosting. | Most substantial customization options | Full customization | Full UX, no UI |
| Authenticator evolution | Inherited from Okta automatically (passkeys, WebAuthn, YubiKey, future authenticators) | Tied to your widget version. Requires upgrades | Tied to SDK version. Varies by platform. Some authenticators (notably passkeys) are limited or platform-dependent | Tied to API version. Limited UI affordances for modern authenticators |
| Learn more |
| Configure Direct Authentication |
For more background on the different deployment models, including basic flows and help with choosing between models, see Okta deployment models — redirect vs. embedded.
Note: Direct calls to the Identity Engine APIs that underpin much of the Identity Engine authentication pipeline aren't supported — use the embedded SDKs instead.
Note: We strongly advise against using WebViews for authentication on mobile apps as this practice exposes users to unacceptable security risks. See OAuth 2.0 for Native Apps. Consider using Okta's native SDKs instead.
Upgrade from Okta Classic Engine to Okta Identity Engine
If you’re a Classic Engine customer who wants to upgrade their apps to use Identity Engine for authentication, go to Identity Engine upgrade overview.
Before you start, identify your Okta authentication integrations and customizations to inventory every sign-in, SDK, API, and automation point that needs testing.
