Test with the Sample Client

Testing with the Sample Client

In order to allow users to register and log into an application of yours using Quasr, this application first needs to be represented by a client within Quasr. In this Getting Started guide, we will simply use the Sample Client that is already provisioned by default upon tenant creation.

The Sample Client is disabled by default, so we will enabled it first.

In the Tenant Administration, click "Accounts" menu item on the left, then click the "edit" icon of the Sample Client and set the Status to Enabled, Save & Exit.

Enabling the sample client under Accounts in the Quasr Tenant Admin UI.

The Sample Client has all necessary settings that we need for simple testing already set, such as allowing the OAuth2 Authorization Code Grant, the ID Token Response Type.

Back in the Client list, click the "Test" icon of the Sample Client. This will generate a Test URL that you can use for testing purposes. The purpose of this test is to allow you to

• see how the enabled authentication factors become available and behave on a login page - where Quasr provides a test login page for development and testing

• see how the ID Token is generated and if everything works as expected or requires refined configuration

Click on the generated test URL.

Test option under Actions in the accounts list under Accounts in the Quasr Tenant Admin UI.

Dialog with test URL

Note the test URL contains an extra parameter mode=test, which makes the default Hosted Login UI switch to test mode, and bypasses the API cache. This mode should only be used for development and testing. Do not bypass the API cache in production.

the scope, according to OAuth2 and OpenID Connect terminology, that the authorization request in this test call is asking for, will simply be just openid. This note will be relevant remember for the explanations about scopes and scores on the next page.

On the upcoming page, we will now see a test login screen. This test login screen is provided by Quasr, however it's purely for development and testing and not meant to be used in production.

You can see that there are two options to authenticate with:

• Quasr Federation (federates with Quasr's root tenant, owned by Quasr BV, where you as a Quasr customer are a regular user of)

• the Username factor we just enabled before

Note that the Time-Based One-Time Password is not listed here yet, as this factor's value is not necessarily unique across all users, therefore cannot be used as the initial step to identify a user account but only later on, in a subsequent step.

Hosted Login UI with initial login screen (test mode).

Let's login with the username we enrolled earlier.

Choose "Username", enter "mastermind", and confirm

Hosted Login UI with step-up login screen (test mode).

Following an ID-First design, Quasr knows that the current user with username "mastermind" only has - beside the Quasr Federation - one additional TOTP factor available, and hence suppresses any other option (such as password, secret), as it does not make sense to offer these options to the current user.

Choose "iPhone", enter the One-Time Password from the Authenticator App on your phone, and confirm.

Login with Authenticator App on the Hosted Login Page (test mode).

Now that the login via username and Time-Based One-Time Password succeeded, the user is redirected to test redirect page jwt.io, which is useful to automatically decode and display an ID Token and its payload.

As can be seen from the screenshot below, the account is identified by the "sub" (subject) claim in the ID token.

Contents of the ID token as shown on jwt.io - notice the sub claim containing the Quasr account UUID

So far, you learned how to enable authentication factors in your tenant, enroll them for your user, and test the factors with a test login page provided by Quasr, which upon successful authentication, provides the client with an ID token.