Authentication

there are several options available to verify the identity of an individual using the jigx app the authentication options are jigx user manager when a user logs into the app on a mobile device, they need to be http //manage jigx com/register http //manage jigx com/register 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 home hub 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\ wjr thj1jy3yod7f9lq48 for oauth configuration steps in jigx management see create and configure a new oauth app in microsoft azure aad docid 1m8gxo1fyoudneyh7fwsm see configuring oauth for ms graph docid\ v8zeelvliqtfw2bvuaxxr data flow with rest jigx fetches the solution definition with a valid jigx token function calls are made to the rest docid\ jjuid0htf7uk1c8rvntkm 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\ hkfushuhy0m6hgkchkj4w 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\ n8b7qmk h62 xfhqvp8gi 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 jigx management on an organizational level the diagram below explains the jigx sso flow see the single sign on (sso) docid\ n8b7qmk h62 xfhqvp8gi and oauth configurations docid g7utdfkvmirkxjxyw2l0 sections to learn how to enable sso and oauth