Authentication

there are several options available to verify the identity of an individual using the {{jigxapp}} the authentication options are jigx user manager when a user logs into the app on a mobile device, they need to be registered in {{jigx}} and assigned a {{jigx}} account this can either be through an email invitation, registering at http //manage jigx com/register http //manage jigx com/register , or requesting to join an organization on the app's {{homehub}} {{jigx}} user manager uses aws cognito for authentication passwords are encrypted and cannot be read by users in {{jigx}} cloud when the user signs in, the credentials are matched in {{jigx}} cloud, and if valid, a {{jigx}} token is returned to the device, where it is stored in the device keychain all subsequent calls are made using the {{jigx}} token in an ssl tunnel jigx user manager with secondary credentials jigx user manager with secondary credentials or authentication providers this requires users to sign in with their {{jigx}} user credentials and secondary credentials such as microsoft or salesforce secondary credentials are set up on a solution using oauth the oauth is referenced by name in the rest (oauth) function call an organization is configured for auto provisioning or a per user invite, requiring administrative approval the aad or okta configuration is stored in aws secured storage in {{jigx}} cloud when the user signs in, the configuration for the organization is retrieved and sent to the mobile device the configuration information runs the user through an oauth loop with the configured external idp, aad, or okta when auto provisioning is enabled, if the user is validated by aad or okta and does not yet exist in the organization, {{jigx}} will automatically create the user and do the necessary {{jigx}} token creation and assignment if the user exists in the {{jigx}} cloud and is authenticated successfully by aad or okta, the user is assigned a {{jigx}} token for all subsequent calls if the organization does not enable auto provisioning, the user can request access, which needs to be approved by an administrator once approved, the user will be provisioned in {{jigx}} see rest authentication docid\ ckhjst84kd5 aylti0fhs for oauth configuration steps in {{jigxmanagement}} see create and configure a new oauth app in microsoft azure aad docid\ x iezs3kw9miu9o9b3jus see configuring oauth for ms graph docid\ lrk 3uhlyqp 6pgsbx4gq data flow with rest jigx fetches the solution definition with a valid jigx token function calls are made to the rest docid\ jrbansm ojn3nf4 dn hu enabled cloud service using the {{jigx}} cloud as a proxy, for example, for ip allowlisting the function calls can use oauth, secrets, and tokens, but not basic authentication oauth configuration, secrets, tokens, and basic authentication are securely encrypted and stored in aws they are not user readable and are only used when the function call is made by a device with a valid {{jigx}} token the result is processed in the {{jigx}} cloud, including all function transforms, continuation, and error transforms, and sent to the device the data is never stored in the {{jigx}} cloud and is only ever kept in memory while the function is executing function calls can be made directly from the device to the rest enabled cloud service using the local rest calls docid\ jp2lszzgo69ixxloqtp7m oauth configuration, secrets, and tokens are stored in the secure keychain on the device when the solution definition is synced the result is processed on the device, including all function transforms, continuation, and error transforms, and the result is stored in sqlite on the device the data never travels through the {{jigx}} cloud sql server is currently not supported for local on device execution data flow with microsoft sql jigx fetches the solution definition with a valid {{jigx}} token jigx function calls are made from the device to sql azure or microsoft sql server, using the {{jigx}} cloud as a proxy, for ip allowlisting the function calls use the connection configuration stored as a secure encrypted secret in {{jigx}} cloud on aws the sql credentials are never sent to the mobile device once saved, the sql credentials are not user readable and are only used by the {{jigx}} cloud when the function call is made by a device with a valid {{jigx}} token the result is processed in the {{jigx}} cloud, including all function transforms, continuation, and error transforms, and sent to the device the data is never stored in the {{jigx}} cloud and is only ever kept in memory while the function is executing single sign on (sso) single sign on (sso) docid\ xvrhqwosolsu23zednkzr authenticates the user against a 3rd party identity provider (idp) when a user logs into the app, {{jigx}} checks if sso is enabled for the organization, the check is based on the domain of the emails linked to the organization next, the oauth configuration is checked to see if it points to the same domain the oauth redirect url is verified for a match against the app configuration the user is then authenticated against the 3rd party idp if the user is a match in {{jigx}} and the 3rd party idp, a {{jigx}} access token is generated, and the user is granted access to the app sso is enabled in {{jigxmanagement}} on an organizational level the diagram below explains the {{jigx}} sso flow see the single sign on (sso) docid\ xvrhqwosolsu23zednkzr and oauth configurations docid\ qj0 8lpafjfbjd85begq6 sections to learn how to enable sso and oauth