Use case scenarios

The SAS architecture supports the use of a token-side or a server-side PIN in either QuickLog or Challenge-Response mode. In addition, the application using the API must support challenges, inner and outer window authentication, and static password authentication. The following sections discuss these features in detail.

Basic authentication

The communication between the application and the server uses challenge messages and states, similar to the RADIUS protocol. The following scenario shows the most basic interaction between the application and the server:

1. The application issues an authentication request that includes the user name, organization name, and a passcode.
2. The server responds with one of twelve possible return codes. For more information, see Authenticate method.

Challenge-Response authentication

The challenge message and state attribute issued from the authenticating server are central to the concept of challenge-response authentication, outer window authentication, and server-side PIN changes. This mechanism is employed to authenticate tokens in challenge-response mode in the following manner:

1. The application issues an authentication request that includes the user name, organization name, and an empty passcode.
2. The server responds with a challenge message containing a challenge string, for example, Challenge: 19863257, and a state attribute. See LOCALIZATION NOTE.
3. The authenticating application responds to the challenge by issuing another authentication request that includes the same user name, organization name, a response, and the state attribute.

Outer window authentication

User authentication through inner and outer window authentication, supported only for hardware tokens, uses challenge messages and state attributes, similar to the Challenge-Response Authentication scenario. In outer window authentication, users provide a match in a large look-ahead window, and respond to a follow-up challenge by providing the exact next OTP from their token. The following sequence illustrates the process:

1. The application issues an authentication request that includes the user name, organization name, and a passcode.
2. The server finds a match for the provided OTP in the outer window, and then issues a challenge to the client containing an outer window authentication string, for example: "Please re-authenticate using the next OTP from your token", and a state attribute.
3. The authenticating application responds to the challenge by issuing another authentication request that includes the same user name, organization name, a response, and the state attribute.

PIN authentication

SAS supports several PIN types:

• No PIN
• Fixed PIN (token-side PIN validation)
• User-changeable PIN (token-side PIN validation)
• Fixed PIN stored on server
• User-changeable PIN stored on server
• Server-changeable PIN stored on server

The SAS authentication mechanism supports incoming passcodes in the following formats:

• [PIN+OTP]
• [OTP]
• [NEWPIN]
• [StaticPassword]
• [null] — empty passcode to request a challenge

PINs stored on the server can be user-changeable or server-changeable. To accommodate this, leverage the challenge framework in the following manner.

User-changeable PIN stored on server

1. The application issues an authentication request that includes the user name, organization name, and a passcode.
2. The server finds a match for the provided OTP and determines that the PIN must be changed.
3. The server issues a challenge to the client containing a PIN change string, for example, "Your PIN has expired. Please enter a new PIN", and a state attribute.
4. The authenticating application responds to the challenge by returning a new PIN and the state attribute.

Server-changeable PIN stored on server

1. The application issues an authentication request that includes the user name, organization name, and a passcode.
2. The server finds a match for the provided OTP and determines that the PIN must be changed.
3. The server issues a challenge to the client containing a PIN change string, for example, "Your new PIN is 628. Please re-authenticate using this new PIN and your next passcode", and a state attribute. See LOCALIZATION NOTE.
4. The authenticating application responds to the challenge by issuing another authentication request that includes the user name, organization name, the new PIN and OTP, and the state attribute.

Static password authentication

SAS offers the option of static password authentication, including enabling the user to change the password. The challenge-response architecture can be used in the following manner:

1. The application issues an authentication request that includes the user name, organization name, and a static password.
2. If the user is not required to change the password and it is correct, the server returns access-accept.
3. If the user is required to change the password, a challenge message is issued to the client, for example, "Your password has expired. Please enter a new password", and a state attribute. See LOCALIZATION NOTE.
4. If a challenge message has been issued in step 3, the authenticating application responds to the challenge by issuing an authentication request that includes the user name, organization name, the new static password, and the state attribute.

MobilePass push authentication

MobilePass push authentication enables users to approve an authentication request through a push notification sent to their enrolled MobilePASS+ authenticator. When push authentication is initiated, the SAS server sends a push notification to the user's MobilePASS+ authenticator. The user approves the request on their MobilePASS+ authenticator to complete authentication.

The following sequence illustrates the push authentication flow:

1. The application issues an authentication request that includes the user name, organization name, and a null or empty passcode.
2. The SAS server delivers a push notification to the user's enrolled MobilePASS+ authenticator.
3. The user approves the push notification on their MobilePASS+ authenticator.
4. The server returns return code 1 (authentication succeeded).

If the user does not respond within the timeout period, the server returns return code 9 (push timed out). If the user explicitly denies the push notification, the server returns return code 11 (push denied).

Numerical challenge authentication

Numerical challenge authentication (push with number matching) adds an additional layer of security to push authentication by requiring the user to match a number displayed in the application with the number shown on their MobilePASS+ authenticator. This helps prevent accidental approval of push notifications.

The following sequence illustrates the numerical challenge flow:

1. The application issues an authentication request that includes the user name, organization name, and a null or empty passcode.
2. The server returns return code 10 (numerical push challenge) along with a challenge number in the challenge field and a state attribute.
3. The application displays the challenge number to the user.
4. The user matches the displayed number with the number shown on their MobilePASS+ authenticator and approves the push notification.
5. The application re-calls the Authenticate method with the same user name, organization name, IP address, passcode, and the challenge and state attributes returned in step 2.
6. The server returns return code 1 (authentication succeeded), return code 9 (push timed out), or return code 11 (push denied by user).