Single Sign On



Appen Single Sign-On (SSO) feature lets users access to Appen using one login. Customers who choose to integrate via SSO can validate usernames and passwords
against their corporate user database rather than Appen managing separate passwords
for each user.
Federated authentication using Security Assertion Markup Language (SAML) allows you to send
authentication and authorization data between Appen and your corporate network. To
enable Single Sign-On for your team, please contact your Customer Success Manager.

Benefits of Single Sign-On

  1. Users have to memorize fewer passwords, thereby increasing usage and time savings.
  2. All established password policies for your corporate network are in effect increasing security for users who have access to sensitive data.

Guide to Set-up SSO Integration

Step 1a (optional): Provide SSO Configuration Details in a QA/Test Appen Organization

  1. Contact your Customer Success Manager or Account Executive to get access to set-up a QA SSO integration in a separate, testing Appen organization.
    • This is highly recommended to ensure the integration is successful before setting up in your Production Appen organization.
  2. Let your Customer Success Manager or Account Executive know which accounts you'd like to be moved into the QA org for testing.
    • We recommend moving at least two users on the QA team. One user to become an Org Admin to set up the integration and one user to test SSO log in after SSO is set-up. 
    • This move is temporary and users can be moved back to the Production organization after QA is complete.
    • Aside from moving existing users, we can also use test accounts if customers have a testing IDP environment of their own. Customers will need to "Sign Up" with these new accounts and provide the emails to their Appen representative to move to the test SSO org.
  3. Once the QA org is created and users are moved, Appen will enable the self-service Single Sign On setting.
  4. The user who is setting up the integration should now see the SSO tab under their “Account” page (also shown in Figure 1 below).
  5. Provide your IdP XML metadata (per instructions below - Step 1b, 2) and add assertion details in your IDP (per instructions below - Step 2).
  6. Once all metadata is successfully saved on the platform and IdP, the test user account should attempt SSO login. 
    • SSO login can be accessed via the IdP provider if the app is added to the user’s workspace 
    • Otherwise, a user can input their email to with no password and the platform will redirect to the integrated IdP for sign-in.
  7. If the test user can successfully sign-on, the same set-up process can be applied to the Production SSO Organization, following the steps directly below.

Step 1b: Provide SSO Configuration Details in Production Appen Organization

  1. Contact your Customer Success Manager or Account Executive to get access to the capability and specify who on the organization should have Org Admin permissions to set-up SSO. 
  2. In Appen, the Org Admin should navigate to their Account Page --> SSO tab.  
    • If you cannot find the SSO tab, please reach out to your Appen Customer Success Manager or Platform Support team.

Note: Only your Organization Admin(s) have access to set up the integration. The SSO tab will not be visible to standard users.

Figure 1: Appen Account Page
  1. Provide your IdP XML metadata. You have 2 options to enter the metadata
    • Provide a URL with IdP metadata (ex: OR copy and paste the XML metadata in the textbox.
    • See the example below. Note: Replace ${certificate} with client certificate
<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="">
 <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
   <md:KeyDescriptor use="signing">
     <ds:KeyInfo xmlns"">
   <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" />
   <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="" />
Figure 2: SSO Settings - Setup SSO
  1. Provide Redirect URLs
    • Appen can optionally configure the following URLs so that users are redirected back to their corporate network when required. If you do not want redirect URLs, please enter the default Appen URL (
    • Important: HTTPs header is required
      • Redirect Error URL: Provide a URL the user should be redirected to when an authentication/authorization error occurs.
      • Redirect logout URL: Provide a URL the should be redirected to when the user is logged out of Appen.
  2. Select the Org-level SSO mode.
    • Org-level (default): Only users who are in the Appenorganization associated with the customer will be able to use SSO. Other users from your company using their corporate emails to login to Appen continue to use Appen credentials, but they will not have access to the organization data or jobs.
      • Example: If is part of the Appen Org named "Company", he will use SSO to access the platform. However, if is not part of the Appen Org named "Company", he will not be able to use the SSO but can log in using Appen credentials.
  3. Go ahead and 'Save' the settings.
  4. After the set-up is completed successfully, you will receive a SAML assertion template to configure in your IdP.


    Figure 3: SSO Settings - SAML Assertion Template

  5. Copy the SAML assertion.
  6. You can go back and edit your SSO set-up by clicking the edit button present in the "SSO Settings" tab.

Step 2: Set-up SAML Assertion Details in IdP

Appen requires the SAML assertion to follow this template provided to you after you complete SSO set-up.

  1. Variables starting with $ are user-specific
  2. Variables starting with # are Identity Provider (IdP) / customer-specific
<?xml version="1.0" encoding="UTF-8"?>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="#{id}" IssueInstant="#{dateAutogeneratedFromIdP}" Version="2.0">
    <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">#{entityId}</saml2:Issuer>
        <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">${emailAddress}</saml2:NameID>
        <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
            <saml2:SubjectConfirmationData NotOnOrAfter="#{dateAutogeneratedFromIdP}" Recipient="{ADAPOrgNameCaseSensitive}"/>
    <saml2:Conditions NotBefore="#{dateAutogeneratedFromIdP}" NotOnOrAfter="#{dateAutogeneratedFromIdP}">
    <saml2:AuthnStatement AuthnInstant="#{dateAutogeneratedFromIdP}">
        <saml2:Attribute Name="team_id" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml2:AttributeValue xmlns:xs=""
                xmlns:xsi="" xsi:type="xs:string">${teamId}
        <saml2:Attribute Name="emailAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
            <saml2:AttributeValue xmlns:xs=""
                xmlns:xsi="" xsi:type="xs:string">${emailAddress}

Assertion Timeout:

  • Appen enforces the "Conditions" field with "NotBefore" and "NotOnOrAfter" values in assertions. If the assertion comes to Appen before one hour the "NotBefore" timestamp value or one hour after the "NotOnOrAfter" timestamp value, the assertion will fail.
  • The one-hour standard delta is to account for system time lag or other possible time differences. The customer will be responsible to post the assertion within the time values sent to Appen.

Note: For <Attribute Name="emailAddress" ... /> element, we will actually accept a Name value like Name="".

Once the necessary IdP configuration is done from your side, the users should be able to login to Appen via SSO. 

Adding Requesters to SSO-Enabled Organizations

  • SSO must be configured on an organization before inviting new requesters. If SSO is enabled on an organization with pre-existing requesters, those requesters will be forced to log-in via SSO after the feature is enabled.

Inviting New Requesters to SSO-Enabled Organizations

  • The Org Admin or Team Admin will need to invite the requester email to the desired team within an SSO-enabled organization
    • This can be done via the Account > Team page
  • Once the invitation is sent, the requester should “Sign Up” with the invited email
    After signing-up, the requester will be added to the designated team and organization All subsequent logins for the requester can now be authenticated via SSO

Additional Instructions:

  • Supported IdPs: Our SSO integration supports SAML and all SAML based SSO Identity Providers.
  • SSO login is supported for the following scenarios:
    • When the user logs in as a job requestor and is accessing any page on
    • When the user has a job requestor account and is trying to access an internal work link to work as an internal contributor.
  • Once a new user is invited to an SSO-enabled organization, there is no need to enter anything in the password field of that Appen login page. The invite user's email will be automatically detected and then redirected to the IDP. Alternatively, there is no need to start a new Appen session on the Appen login page and the session can start directly from the IdP site. 


Figure 4: How to enable the Internal Channel option


IDP Application Set-Up

When setting up SSO integration, our platform will ask for either a URL to your IDP metadata or the plain text snippet of your metadata and certificate. To generate this information, proceed with adding a new application to your IDP with the following inputs:

  • Single Sign On / Endpoint URL:

  • Entity ID / Audience URI:

    • The globally unique name for a SAML entity.

    • ADAP's current entityID is com:figure-eight:sp

  • Default Relay State
    • Identifies a specific application resource in an IDP initiated Single Sign-On scenario. In most instances this is blank.
  • Application username (Name ID)
    • The application username will be used for the assertion's subject statement. Default value is “Okta username”. Please mention if you have a special requirement.

      • Email

  • Attribute Statements
    • You can federate user profile field values to SAML attributes. Typical attributes are first name, last name, username (email format). List all attributes you require for your application.

    • Please provide the exact (case sensitive) attribute name.

      • Name = emailAddress

        Name format = Basic

        Value =

  • Name ID format
    • Identifies the SAML processing rules and constraints for the assertion's subject statement. Default value is 'Unspecified' unless the application explicitly requires a specific format.
      • EmailAddress





Was this article helpful?
26 out of 28 found this helpful

Have more questions? Submit a request
Powered by Zendesk