The Okta Integration Network (OINAn acronym for the Okta Integration Network. The OIN is comprised of thousands of public, pre-integrated business and consumer applications. As an on-demand service, OIN integrations are continuously validated, always up to date, and constantly growing both in number and capability. Okta performs a single integration with an ISV or SP, providing thousands of end users with point-and-click customization for their orgs.) is a catalog of thousands of pre-integrated applications that make it easy to manage authentication and provisioning for all of your users. We offer the industry’s broadest and deepest set of integrations, and we constantly monitor the network, maintaining connections and adding new ones by the day.
Okta enables admins to provide SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones. access to cloud, on-premise, and mobile applications. After the applications are configured, end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. can sign into Okta and then launch any of their web apps without having to reenter their credentials. For details on adding applications to Okta, configuring the apps and assigning them to end users, see The Applications Page.
Okta establishes a secure connection with a user's browser and then authenticates the user to Okta-managed apps using one of two SSO integration methods:
- Okta’s Secure Web AuthenticationAuthentication is distinct from authorization, which is the process of giving individuals access to system objects based on their identity. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual. Authentication methods and protocols include direct auth, delegated auth, SAML, SWA, WS-Fed, and OpenID Connect. (SWAAn acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully.)
- Federated (supporting SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. or another proprietary federated authentication protocol)
Okta provides access to cloud apps with the Okta Integration Network (OIN), a collection of thousands of supported applications. SSO protocols and provisioning APIs are maintained by Okta. The applications in the OIN can use SWA, SAML or OpenID Connect, or proprietary APIs.
Okta also provides integrations for on-premise web-based applications. You can integrate on-premise apps using SWA for SSO, SAML toolkits, and support for provisioning and deprovisioning into applications that expose provisioning APIs publicly.
Okta provides integrations for mobile apps whether they are HTML5 web apps optimized for mobile platforms, Native iOS, or Android apps. You can access any web application in the OIN with SSO from any mobile device. Mobile web apps can use industry-standard SAML or Okta’s SWA SSO technology. Native applications like Box Mobile can be integrated using SAML authentication for registration and OAuth for ongoing usage.
SWA was created for apps that do not support federated SSO. When you enable SWA for an appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in., end users see a link below their app icon on their My Applications pageThis is the central home page for Okta users. It is the first page that appears after signing into Okta each day, and displays the chiclets that represent an end user’s applications.This page will usually have a URL that looks something like acme.okta.com/app/UserHome.. Selecting the link enables them to set up and update their credentials for that app. Okta stores the end user's credentials in an encrypted format using strong AES encryption combined with a customer-specific private key. When end users click an application icon, Okta securely posts their credentials to the app login page over SSL and the user is automatically signed in.
By configuring users' sign-in options, you can make their SWA credentials match their Okta credentials so additional sign-ins are not required after you have signed into Okta.
When you configure your sign-in options, you can set up SWA so that:
- User sets username and password
- Administrator sets username and password
- Administrator sets username, user sets password
- Administrator sets username, password is the same as user's Okta password
- Users share a single username and password set by administrator
You can also customize the userName mapping (Application Username Format) and configure its Push Status (Update application username). This determines how you want the app to handle updates to the user's Okta userName mapping.
Create Only: The Okta-to-App userName is applied when the user is first assigned to the app and cannot be changed later.
Create and Update: The Okta-to-App userName is applied when the user is first assigned to the app. If profile is updated later, the user will be updated automatically.
Note: The SWA sign-in options are not configurable when Push Okta password is configured as a provisioning option. (Update application username) is not configurable when the userName is mapped to the default template.
Administrator Sets Username and Password
This second option on the Sign On tab is one that provides the most robust level of adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. control. It allows the admin to set all usernames and passwords for an app instance, after which the credentials are never exposed to their Okta end-users. This option provides a way to shut off user access to the credentials of sensitive apps. For this to work, ensure that the user does not have an alternative way to reset their app's password. It is also useful for cases where admins must supply a new, obfuscated password to an Okta user—no active communication with the user is required.
To set the usernames and passwords for a particular SWA app, do the following:
- Outside of Okta, access the downstream app you wish to assign.
- Establish the username and password within the app.
- Return to Okta and access or create the app in the OIN.
- Choose the Sign On tab (or step) on the app page.
- Choose Administrator sets username and password and click the Next button.
- Assign the app to users and assign their usernames and passwords.
Note: The admin-created password can only be viewed when initially created. After sending, the password is no longer visible to the admin. To change the password, it must be reset in the downstream app, then reset in Okta.
If the chosen app was previously assigned to an established Okta group, please note that group members do require the individual, manual updates of usernames and passwords for each user.
The Reveal Password feature is disabled for this option, as end-users will never have access to their passwords.
Okta provides integration toolkits to enable apps that are not in the OIN to support SAML. You can obtain SAML integration toolkits for .NET, Java, and PHP platforms.
SSO for Active Directory-Authenticated Web Apps
You can integrate on-premise web apps with Okta. On-premises web apps that use Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. (AD) credentials for authentication do not use Integrated Windows Authentication (IWA), but instead require users to enter their AD credentials when they sign in on a browser. When you configure Okta to delegate authentication to AD, signing in to internal web apps can also be automated.
Here's how Okta enables SSO for AD-authenticated internal web applications:
- Configure Okta to delegate authentication to AD.
- Customer has on-premises apps authenticating to AD.
- Users sign into Okta with AD credentials.
- Users access their internal web apps with SWA using AD credentials.
- The internal web apps authenticate users against AD.
Okta uses SWA to automatically sign users into internal web apps. When you configure an internal web application to delegate authentication to AD (the same source to which Okta delegates authentication), Okta captures the user’s AD password during the sign-in process and automatically sets that password for that user in any applications that also delegate to AD. This enables users to click a link to access these apps, and then sign in automatically. Okta synchronizes the AD password securely. If the password is later changed in AD, this event is captured during sign-in to Okta and immediately updated in the secure password store for that app, ensuring that the next sign-in attempt is successful.
There are two common SWA template apps that you can use to create apps on demand—one that does a POST to a sign-in page (the Template App) and one that uses a plugin to POST (the Template Plugin App). These template apps allow you to create application integrations in real-time on a running system.
The Okta browser plugin enables you to automatically sign into applications that would otherwise require you to manually enter your credentials. For more information on the browser plugin, see About the Browser Plugin.
Okta Mobile uses SSO to extend its functionality to apps on iOS and Android devices. The Okta Mobile application provides an embedded Okta browser and app menu. You can download and install the Okta Mobile app from the Apple App store and Google Play store. For details on distributing mobile apps to end users, see Enable access to managed mobile apps.
Note: Not all public mobile apps available from the Apple and Google app stores are available for distribution to OMMAn acronym for Okta Mobility Management. OMM enables you to manage your users' mobile devices, applications, and data. Your users enroll in the service and can then download and use managed apps from the Apps Store. Managed apps are typically work-related, such as Box or Expensify. As an administrator, you can remove managed apps and associated data from users' devices at any time. You can configure policies, such as data sharing controls, on any of your managed apps. See Configuring Okta Mobility Management for more information.-enrolled users through the App Store accessible through Okta Mobile. (Mobile App store for iOS device end users; Play for Work for Android device end users.) Before you can distribute a public mobile app to your end users through OMM, Okta Support must add it to the Okta Integration Network (OIN). To submit a request to add a public app to the OIN, open a case and provide the app name and the link to the app in the appropriate app store. Screenshot
You can optionally configure Microsoft Exchange ActiveSync (EAS) to synchronize your users' mobile devices with your Exchange server. EAS is a protocol that enables your mobile devices to connect to your Exchange server. This pushes end users' email, calendar, and contacts directly to their device(s).
Note: Google's implementation of Microsoft Exchange ActiveSync (EAS) is not available for free Google accounts. It is available for paying G Suite for Business, Education and Government customers.
If you use Office 365 or G Suite, this is an important configuration procedure you must complete for each app that connects with your Exchange server.
To configure EAS:
- Scroll to the Exchange Active Synch Settings section of the app's Mobile tab.
- Click Edit.
- Select Enable Exchange Active Synch.
Note: Google discontinued support for the Divide Productivity app. More
Google discontinued support for the Divide Productivity app and removed it from the Google Play store. Divide Productivity included email, calendar, tasks, notes, and contacts capability. Google provides similar capability in their Gmail and Google Calendar apps for Android. In early March 2017, Okta began preparing for the Divide Productivity End of Life (EOL) by making Gmail available for Android for Work profiles on Okta Mobility Management (OMM)-enrolled devices.
To make sure that your new Android users enrolling in OMM have access to an email clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. , Okta recommends that you do the following if you have not already:
- Inform your end users about the above changes and recommend that they set up Gmail for their managed mobile account.
- Replace the capability formerly provided by the Divide Productivity app by distributing Gmail and Google Calendar to all Android OMM-enrolled end users. For details, see Enabling Mobile Access to Applications.
- If you distributed Divide Productivity with any the following apps in the past, be sure to make Gmail available through them:
- Microsoft Office 365
- Outlook Web Access — 2003
- Outlook Web Access — 2007
- Outlook Web Access — 2007 (cookie-based)
- Outlook Web Access — 2010
- For Office 365 or G Suite:
Office 365 / Android: You need to deploy the Gmail app (available by default) to enable mail configuration within Android for Work.
G Suite / Android: You must deploy the Gmail app (available by default) to enable mail configuration within Android for Work.
The exchange servers for these are hosted in the cloud and the Host URL field is automatically populated and cannot be edited.
Profile Name: You can optionally specify a profile name. This is the name that is displayed on your end user's device. If you modify this field later, email is resynchronized across all devices.
- For On-Premises Exchange servers:
Android: You must deploy the Gmail app (available by default) to enable mail configuration within Android for Work.
This assumes that you have already added a Microsoft Outlook Web Access (OWA) app to your orgThe Okta container that represents a real-world organization..
Specify the Host URL of the on-prem exchange server.
- Click Save.
- SWA cannot sign users into applications that require captcha. End users must manually respond to a captcha.
- If you configured EAS but AD Delegated Authentication is enabled, you must do one of the following in order for the device to be updated with a new password:
- Require users to change their password in Okta, which in turn will push that password to Windows.
- Enable the app's Sync Okta Password setting (see Provisioning and Deprovisioning) and require the user to reset their password in Windows. The next time the user logs into Okta, the password is updated and pushed to the user's device.
The App Integration Wizard allows you to create custom SWA, SAML 2.0, and OpenID Connect (OIDCOpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID) apps. For more information, see Using the App Integration Wizard.