Mobile SSO

Updated 2 years ago by Leigh Hutchens

From a user perspective, you start with going into the mobile apps log in page. Here you select "settings", after that the user types in the name of the environment he/she wants to log into. When you have chosen the environment you can click "log in" and get redirected to the external Oauth log in page, here you enter your credentials and log in, after that you are redirected and logged in to the Quinyx mobile app.

Setup

Quinyx offers a SAML 2.0 SP-initiated SSO for the web application and OAuth 2.0 for the native mobile apps. For mobile we currently support following OAuth 2.0 implementations: Azure/ADFS, Oracle OAM, Google Auth. User data integration can come from multiple sources and use our username/password authentication for users not part of the main SSO solution. ADFS is the underlying service that Azure & OKTA use, Active Directory Federation Services (ADFS) is a Single sign-on (SSO) solution created by Microsoft. As a component of Windows Server operating systems, it provides users with authenticated access to applications that are not capable of using Integrated Windows Authentication (IWA) through Active Directory (AD).

Start with a browser with Dev Tools activated. Navigate to the login URL (authorize):

Here the basic setup for customer’s mobile SSO will be explained. This view can be found in Classic under Settings > Global > Mobile SSO.

Environment: rules which environment the configuration will use, notice that we only can have one distinct environment per customer.

Logo: Full path to the customer logo which mobile application will show when employees are trying to log in via SSO.

Login Url: This is the full path to the customer identity provider service where employees should login using their identity provider’s credentials, this page is loaded when employee loads up customer SSO configuration in the mobile application and clicks “Log in“.

Redirect url: Should start with “https://quinyx.com/“ and can be ended with anything, customer name without spaces is fine.

Display: Not used for now.

Implementation: Choose appropriate value here according to the customer’s Identity provider.

  • Custom Azure/ADFS only looks at values before "@example.com"

Endpoint url: This is the endpoint url from Identity provider’s service which Quinyx backend will target to receive Access (Id) and Refresh tokens. This step is performed after the employee successfully logs in into Identity provider’s service defined under “Login Url“. For Azure Endpoint url is known as “Authorisation code request URL”.

Client Id and Client Secret: These should be provided from the customer.

Idp field to match: Which field from the received Access or Id token we should use to compare it against Quinyx database in the employees table. This should be configured from customer’s Identity provider.

QWFM Field to match: Value that is taken from the “Idp field to match“ and is compared against database table column in the “employees” table in Quinyx database. It should be “email”, “loginId“, “badgeNo” or “cardNo“.

  • This must be a unique value across all Quinyx customers and is given on a "first come first serve" basis.
  • It can't be the same as an email. For example email@example.com can either exist as email or loginid, but not both. An email can't be the same as loginid anywhere in Quinyx.
The above applies only to loginId.

Idp token to use: By default it should be Access Token. In some specific configurations Id token is used.

How Did We Do?