iOS Authenticator SDK v2 Integration

Adding the Authenticator SDK to your iOS Project

To add the Authenticator SDK to your iOS project, follow these instructions:

  1. Add WhiteLabel.bundle and WhiteLabel.framework to your project.
  2. You should see WhiteLabel.bundle under the Copy Bundle Resources section of your target’s Build Phases.
  3. Under Link Binary With Libraries, you should see WhiteLabel.framework.

After the Authenticator SDK has been successfully added, you will need to link the following frameworks to your project:

  • AVFoundation
  • CoreBluetooth
  • CoreData
  • CoreGraphics
  • CoreLocation
  • CoreVideo
  • Foundation.Framework
  • ImageIO
  • LocalAuthentication.Framework
  • MobileCoreServices
  • Security
  • UIKit

Note

For Authenticator SDK v2.0 and below, under your target’s Build Settings -> Other Links Flags, ensure that you add the -ObjC flag.

Initializing the Authenticator SDK

First, import the Authenticator framework to your delegate and then initialize WhiteLabelManager:

Example:

#import <WhiteLabel/WhiteLabelManager.h>

Next, initialize the shared client:

Prototype:

- (void)initSDK:(NSString*)sdkKey;

Example:

[[WhiteLabelManager sharedClient] initSDK:@"abcDEfgHIjkLMNOPqrsTuVwxYZ01234567890"];

The SDK key (sdkKey) for your directory can be found within Dashboard inside the directory details page which can be accessed from your Organization details page.

Register For APN Token

In order to identify the device as well as to receive push notifications from the LaunchKey Platform (more on that later), you need to register for an Apple Push Notification token. To register for a notification token, make this call:

[[UIApplication sharedApplication] registerForRemoteNotifications];

Next, in the AppDelegate callback function didRegisterForRemoteNotificationsWithDeviceToken, make a call to the WhiteLabelManager to register the device’s token with the Authenticator SDK via SetNotificationToken like this:

Prototype:

- (void)setNotificationToken(NSData *)deviceToken;

Example of callback and registering the token with the Authenticator SDK:

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken
    {
    [[WhiteLabelManager sharedClient] setNotificationToken:deviceToken];
    }

Adding Location Request to info.plist

Next, open your project’s priority list file (usually info.plist). Right-click a row in the info.plist and click Add Row, enter NSLocationWhenInUseUsageDescription and NSLocationAlwaysUsageDescription as the key and leave the Value section blank. This will prompt the User for access to their location when geo-fencing is enabled.

For the Authenticator SDK to properly work with devices running iOS 10 and up, please also add the following keys to the .plist:

  • NSBluetoothPeripheralUsageDescription
  • NSCameraUsageDescription

Configuration Options - Optional

With WhiteLabelConfigurator, you can modify various aesthetic and security configuration options for the available views by modifying the WhiteLabelConfigurator sharedConfig object with the following calls:

First, import the WhiteLabelConfigurator.h:

Example:

#import <WhiteLabel/WhiteLabelConfigurator.h>

Then, modify any or all of the following calls:

Primary Color

The primary color is the most widely used color as the Navigation Bar color across all screens. To define this color, modify the Configurator and pass in a custom UIColor object with this call:

Prototype:

- (void)setPrimaryColor:(UIColor*)primaryColor;

Example:

[[WhiteLabelConfigurator sharedConfig] setPrimaryColor:[UIColor redColor]];

Primary Text and Icons Color

The primary text and icons color is the color used for the texts and icons in the navigation bar across all screens. To define this color, modify the Configurator and pass in a custom UIColor object with this call:

Prototype:

- (void)setPrimaryTextAndIcons:(UIColor*)primaryTextAndIcons;

Example:

[[WhiteLabelConfigurator sharedConfig] setPrimaryTextsAndIcons:[UIColor darkGrayColor]];

Secondary Color

The secondary color is used to indicate a relation action or information. To define this color, modify the Configurator and pass in a custom UIColor object with this call:

Prototype:

- (void)setSecondaryColor:(UIColor*)secondaryColor;

Example:

[[WhiteLabelConfigurator sharedConfig] setSecondaryColor:[UIColor greenColor]];

Background Color

The background color is the main color of the background in various screens. To define this color, modify the Configurator and pass in a custom UIColor object with this call:

Prototype:

- (void)setBackgroundColor:(UIColor*)backgroundColor;

Example:

[[WhiteLabelConfigurator sharedConfig] setBackgroundColor:[UIColor whiteColor]];

SSL Pinning (Extra Security)

The Authenticator SDK uses SSL for network communication to the LaunchKey Platform API to ensure secure data transmission. However, to protect against eavesdropping and ensure that man-in-the-middle attacks cannot occur over this connection, you should enable SSL pinning which will verify the hostname and SSL certificate returned from the Platform API handshake exactly matches those that are bundled in your Mobile App. If the certificate cannot be verified, all connections to the Platform API are terminated.

Note

SSL pinning is turned OFF by default.

To bundle the LaunchKey SSL public keys in your project, drag and drop the LaunchKey public key certs (.cer files) to your project’s Supporting Files folder. To verify that these have been properly added to your project, go to Build Phases, and under Copy Bundle Resources, you should see the .cer files listed accordingly.

Warning

SSL pinning should only be enabled if you fully understand the consequences of enabling this feature as connectivity to the LaunchKey Platform API can be interrupted if SSL pinning is not properly configured.

Prototype:

// Turn OFF
- (void)turnOffSSLPinning;

// Turn ON
- (void)turnOnSSLPinning;

Example:

// Turn OFF
[[WhiteLabelConfigurator sharedConfig] turnOffSSLPinning];

// Turn ON
[[WhiteLabelConfigurator sharedConfig] turnOnSSLPinning];

Set Custom Font

In Authenticator SDK v2.1 and up, you can pass a custom font to the Authenticator SDK that will be seen in views embedded in your authenticator, such as the Linking View, Security View, Auth Request View, etc. If the font is supported by Xcode, just pass the name as a NSString in the following call:

Prototype:

- (void)setFont:(NSString*)customFont;

Example:

[[WhiteLabelConfigurator sharedConfig] setFont:@"Roboto"];

If the font is not supported by Xcode, make sure to import the files to your project, include them in the target, and add them to the application plist under a new row called "Fonts provided by application" where you name all the filenames of the font in an array.

Set Endpoint

In Authenticator SDK v2.1 and up, you can override the endpoint by calling the following and passing the endpoint as a NSString:

Prototype:

- (void)setEndpoint:(NSString*)endpoint;

Example:

[[WhiteLabelConfigurator sharedConfig] setEndpoint:@"api.yourservice.com"];

Note

If you override the endpoint, be sure to set the endpoint before you initialize the SDK.

If you override the endpoint and turn on SSL pinning, be sure to drag and drop your public key certs (.cer files) to your project’s Supporting Files folder and that the endpoint exactly matches the hostname in the certificate bundled in the Mobile App.

Set Key Pair Size

In Authenticator SDK v2.3 and up, you can set the size of the key pair generated when linking the device. It can be any valid size value from 2048 up to 4096 bits. The value will be set to the closest valid value if it is outside of that range and/or invalid. If the key pair size is not set through the WhiteLabelConfigurator, then the default value will be used (4096). There are constants for the common key pair sizes available in the WhiteLabelConfigurator.

Prototype:

- (void)setKeyPairSize:(int)keyPairSize;

Example:

[[WhiteLabelConfigurator sharedConfig] setKeyPairSize:keypair_maximum];

Note

If you are setting the key pair size, be sure to do so before you initialize the SDK.

Interacting with Available Views/Calls

There are various views that can be embedded in your authenticator directly as well as public calls to retrieve the same information that the embedded views display so that your Mobile App can create custom views if needed.

Display Linking View

use this view in the device linking process to give your User the ability to scan a QR linking code or manually enter a 7-character alphanumeric linking code. Pass YES to show the QR Camera to link or NO to show the manual entry option for linking.

Note

Your Mobile App can also link the user’s device from within your own custom view using a method exposed by the SDK. To do this, read Performing Actions Directly In Your App - Optional.

To display the Linking View, make the following call:

Prototype:

- (void)showLinkingView:(UIViewController*)parentViewController withCamera:(BOOL)camera withLinked:(linkedBlock)linked withFailure:(failureBlock)failure;

Example:

[[WhiteLabelManager sharedClient] showLinkingView:self withCamera:YES withLinked:^{

    } withFailure:^(NSString *errorMessage, NSString *errorCode) {

    }];

This will allow the end user to either scan the QR linking code or manually enter the 7-character alphanumeric code that your service will present to them. The withLinked callback will be called if the User has successfully linked their device (see next).

To determine whether a User has been successfully linked or not, call:

Prototype:

- (BOOL)isAccountActive;

Example:

[[WhiteLabelManager sharedClient] isAccountActive];

Display Auth Request View

To give your Users the ability to authenticate and respond to pending Auth Requests from your service, first import the AuthRequestViewController.h file:

Example:

#import <WhiteLabel/AuthRequestViewController.h>

Next, initialize the AuthRequestViewController:

Prototype:

- (id)initWithParentView:(UIViewController*)parentViewController;

Example:

AuthRequestViewController *requestView = [[AuthRequestViewController alloc] initWithParentView:self];

To embed this view, first define a Container View in your Mobile App:

Example:

@property (weak, nonatomic) IBOutlet UIView *containerView;

Then add the AuthRequestViewController view as the Child View Controller. For example:

Example:

[self addChildViewController:requestView];
[self.containerView addSubview:requestView.view];
[requestView didMoveToParentViewController:self];

Then you can check if there is a pending Auth Request by calling:

Prototype:

-(void)showRequest:(UIViewController*)parentViewController withSucess:(successBlock)success withFailure:(failureBlock)failure;

Example:

[requestView showRequest:self withSucess:^{

    } withFailure:^(NSString *errorMessage, NSString *errorCode) {

    }];

Note

The Auth Request View will only be displayed if isAccountActive returns true, meaning the User has successfully linked their device.

In LaunchKey v2.3.2 and up, you can now use the following call to display the Auth Request View and retrieve a NSError object if there are no pending Auth Requests. Please note that the "-showRequest" call will be deprecated:

Prototype:

-(void)checkForPendingAuthRequest:(UIViewController*)parentViewController withCompletion:(completion)completion;

Example:

[requestView checkForPendingAuthRequest:self withCompletion:^(NSError *error) {
    if(error != nil)
    {
        NSLog(@"Error: %@", error);
    }
}];

In LaunchKey v2.2 and up, you can implement your own UI based off of triggered events by adding the following observers:

requestApproved

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(requestApproved) name:requestApproved object:nil];

Once a request has been approved and the observer has been the added, the selector method (requestApproved in this example) will be called:

-(void)requestApproved
{

        // This will be called when an auth request has been approved... Add any custom UI here

}

requestDenied

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(requestDenied) name:requestDenied object:nil];

Once a request has been denied and the observer has been the added, the selector method (requestDenied in this example) will be called:

-(void)requestDenied
{

        // This will be called when an auth request has been denied... Add any custom UI here

}

possibleOldRequest

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(oldRequest) name:possibleOldRequest object:nil];

If an old request has been responded to and the observer has been the added, the selector method (oldRequest in this example) will be called:

-(void)oldRequest
{

        // This will be called when the user responds to a possible old request... Add any custom UI here

}

In LaunchKey v2.2.1 and up, you can add the following observer to know when an auth request has been hidden after a security factor has been added from the auth request flow:

requestHidden

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(requestHidden) name:requestHidden object:nil];

Once an auth request has been hidden, the selector method (requestHidden in this example) will be called:

-(void)requestHidden
{

        // This will be called when an auth request has been hidden after setting up additional security factors from the auth request flow

}

Display Security View

The Authenticator SDK provides the User with certain auth-related settings through this view (e.g. enable/configure authentication factors). To display the security settings, make the following call:

Prototype:

- (void)showSecurityView:(UIViewController*)parentViewController withUnLinked:(unlinkedBlock)unlinked;

Example:

[[WhiteLabelManager sharedClient] showSecurityView:self withUnlnked:^{

    }];

The withUnLinked callback will be called if the User has unlinked their device from your directory.

Authorizations View

First, import the AuthorizationsViewController.h file

Example:

#import <WhiteLabel/AuthorizationViewController.h>

Next, initialize the AuthorizationViewController:

Prototype:

-(id)initWithParentView:(UIViewController*)parentViewController;

Example:

AuthorizationViewController *authorizationsView = [[AuthorizationViewController alloc] initWithParentView:self];

Now you can call the following that returns a NSMutableArray of all the Authorizations:

Prototype:

- (void)getAuthorizations:(Completion)block;

Example:

[authorizationsView getAuthorizations: :^(NSMutableArray* array, NSError *error){

}];

In LaunchKey v2.3.2, you can call the following that returns a NSArray of LKWApplication objects:

Prototype:

- (void)getApplications:(getApplicationsCompletion)block;

Example:

[authorizationsView getApplications: :^(NSArray* array, NSError *error){

    }];

Please note, be sure to import the LKWApplication.h into your project to make use of the new LKWApplication objects that are being returned.

To embed this view, first define a Container View in your Mobile App:

Example:

@property (weak, nonatomic) IBOutlet UIView *containerView;

Then add the AuthorizationViewController view as the Child View Controller. For example:

Example:

[self addChildViewController:authorizationsView];
[self.containerView addSubview:authorizationsView.view];
[authorizationsView didMoveToParentViewController:self];

You can refresh the Authorizations list of this embedded view by calling:

Prototype:

- (void)refreshAuthsView;

Example:

[authorizationsView refreshAuthsView];

Also, if you have embedded the Authorizations View, there is a label positioned in the middle of the view when there are no Authorizations. You can hide this label if you need to by calling the following and passing a Boolean value:

Prototype:

- (void)hideNoAuthsLabel:(BOOL)hide;

Example:

[authorizationsView hideNoAuthsLabel:YES];

If you need to change the text color of the label displayed in the middle of the view when there are no Authorizations, call the following and pass in a custom UIColor object:

Prototype:

- (void)setNoAuthsLabelTextColor:(UIColor*)color;

Example:

[authorizationsView setNoAuthsLabelTextColor:[UIColor redColor]];

If you need to clear an Authorization, you can use the following call and pass the index from the returned list of Authorizations that you want to clear:

Prototype:

- (void)clearAuthorization:(NSInteger)cellIndex;

Example:

[authorizationsView clearAuthorization:0];

In LaunchKey Authenticator SDK v2.3.2 and up, you can use the following call to clear an Application by passing the LKWApplication object you want to clear. Please note that the "-clearAuthorization" call will be deprecated:

Prototype:

- (void)clearApplication:(LKWApplication*)application;

Example:

[authorizationsView clearApplication:applicationObject];

Display Codes View

use this view to display the TOTP view where your user can scan a TOTP QR Code, or manually enter a TOTP.

Prototype:

-(void)showTokensView:(UIViewController*)parentViewController withUnLinked:(unlinkedBlock)unlinked;

Example:

[[WhiteLabelManager sharedClient] showTokensView:self withUnLinked:^{

    }];

Devices View

First, import the DevicesViewController.h file

Example:

#import <WhiteLabel/DevicesViewController.h>

Next, initialize the DevicesViewController:

Prototype:

-(id)initWithParentView:(UIViewController*)parentViewController;

Example:

DevicesViewController *devicesView = [[DevicesViewController alloc] initWithParentView:self];

Now you can call the following that returns a NSMutableArray with a list of linked Devices under that User. The first item returned in the list is the currently linked device:

Prototype:

- (void)getDeviceList:(Completion)block;

Example:

[devicesView getDeviceList:^(NSMutableArray* array, NSError *error){

    }];

In LaunchKey v2.3.2, you can call the following that returns a NSArray of LKWDevice objects:

Prototype:

- (void)getDevices:(getDevicesCompletion)block;

Example:

[devicesView getDevices: :^(NSArray* array, NSError *error){

    }];

Please note, be sure to import the LKWDevice.h into your project to make use of the new LKWDevice objects that are being returned.

In Authenticator SDK v2.1 and up, you can call the following which returns a NSString that is the name of the currently linked device:

Prototype:

- (NSString*)getCurrentDevice;

Example:

[devicesView getCurrentDevice];

In Authenticator SDK v2.3.2 and up, you can call the following and the current LKWDevice object will be returned:

Prototype:

- (LKWDevice*)currentDevice;

Example:

[devicesView currentDevice];

To embed this view, first define a Container View in your Mobile App:

Example:

@property (weak, nonatomic) IBOutlet UIView *containerView;

Then add the DevicesViewController view as the Child View Controller. For example:

Example:

[self addChildViewController:devicesView];
[self.containerView addSubview:devicesView.view];
[devicesView didMoveToParentViewController:self];

You can refresh the Devices list of this embedded view by calling:

Prototype:

- (void)refreshDevicesView;

Example:

[devicesView refreshDevicesView];

Logs View

First, import the LogsViewController.h file

Example:

#import <WhiteLabel/LogsViewController.h>

Next, initialize the LogsViewController:

Prototype:

-(id)initWithParentView:(UIViewController*)parentViewController;

Example:

LogsViewController *logsView = [[LogsViewController alloc] initWithParentView:self];

Now you can call the following that returns a NSMutableArray with a list of Logs:

Prototype:

- (void)getLogs:(Completion)block;

Example:

[logsView getLogs:^(NSMutableArray* array, NSError *error){

    }];

In LaunchKey v2.3.2, you can call the following that returns a NSArray of LKWLogEvent objects:

Prototype:

- (void)getLogEvents:(getLogEventsCompletion)block;

Example:

[logsView getLogEvents: :^(NSArray* array, NSError *error){

    }];

Please note, be sure to import the LKWLogEvent.h into your project to make use of the new LKWLogEvent objects that are being returned.

To embed this view, first define a Container View in your Mobile App:

Example:

@property (weak, nonatomic) IBOutlet UIView *containerView;

Then add the LogsViewController view as the Child View Controller. For example:

Example:

[self addChildViewController:logsView];
[self.containerView addSubview:logsView.view];
[logsView didMoveToParentViewController:self];

You can refresh the Logs list of this embedded view by calling:

Prototype:

- (void)refreshLogsView;

Example:

[logsView refreshLogsView];

Configure Service For Push Notifications - Optional

Although optional, we recommend using push notifications in your Mobile App to provide a better user experience. With push notifications, the Platform will push alerts to your User’s device to notify them of pending Auth Requests from your service and with Authenticator SDK v2.3.1 and up, push alerts will notify the User's device if it has been unlinked. Additionally, your Mobile App can check for these notifications and automatically display the Request View to the User. To use this feature, follow these steps:

Warning

Push notifications are dependent upon the proper function of the Apple Push Notification system and your user’s mobile carrier. Slowdowns, outages, or other problems may affect the speed and ability of your user’s mobile device to receive push notifications. Therefore, in addition to push requests, it’s highly recommended that you provide a manual option for your user to check for pending Auth Requests within your mobile app.

Obtain APN Certificate from Apple Developer Portal

In order for the LaunchKey Platform to be able to send push notifications to your Mobile App on your behalf, you must first obtain an Apple Push Notification Certificate. To do this:

  1. Log into the Apple Developer Portal at https://developer.apple.com and click on the Certificates, Ids & Profiles section. (This assumes you have already setup push notifications for your mobile app)

  2. Under the Certificates section, find the Production Push Notification certificate you created for your mobile app (this should be the certificate you use in production for your mobile app) and click the Download link to download the certificate to your Mac.

  3. Once downloaded, double-click on the certificate file to add it to your Keychain’s Certificate section.

  4. Open Keychain Access, find the Push Notification certificate that you just added, click on the arrow to

    expand the Certificate + Key, select both the Certificate + Key, then right-click and choose Export 2 items

  5. When prompted, save this certificate with a .p12 file extension and leave the password field empty. Move on to the next step.

Add APN Certificate to directory

Next, add the APN certificate to your directory settings in Dashboard:

  1. Log into Dashboard and click on the Organizations link.
  2. Click on your Organization, then click on the White Label tab. Select the directory you want to authorize push notifications for.
  3. Finally, select the Push Notification tab, and under the iOS section, upload your APN certificate with the .p12 file extension.

Intercepting Push Notifications - Optional

In LaunchKey v2.3.0 and below, if you’re using push notifications, your Mobile App will receive a push notification regarding the pending Auth Request. Your Mobile App should intercept this notification in order to trigger the Auth Request View. You can intercept the push notification via the didReceiveRemoteNotification callback in the AppDelegate:

- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo { }

In the didReceiveRemoteNotification callback, your Mobile App should trigger the Request View in order to display the pending Auth Request to your User.

In LaunchKey v2.3.1 and up, the Mobile App will receive a push notification either regarding a pending Auth Request or if the device has been unlinked. The WhiteLabelManager will handle the push notification received and post the corresponding NSNotification with the following call in the didReceiveRemoteNotification callback in the AppDelegate as long as the userInfo is passed to the call:

Prototype:

- (void)handleRemoteNotification:(NSDictionary*)userInfo;

Example:

[[WhiteLabelManager sharedClient] handleRemoteNotification:userInfo];

If the push notification is due to the device being unlinked, you can add the following observer:

deviceUnlinked

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(deviceUnlinked) name:deviceUnlinked object:nil];

The selector method (deviceUnlinked in this example) will be called:

-(void)deviceUnlinked
{

        // This will be called once the device is successfully unlinked or when the API returns an error indicating the device is unlinked

}

If the push notification is due to an incoming Auth Request, you can add the following observer:

requestReceived

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(requestReceived) name:requestReceived object:nil];

The selector method (requestReceived in this example) will be called:

-(void)requestReceived
{

        // This will be called when the device has received a pending Auth Request

}

Performing Actions Directly In Your App - Optional

The Authenticator SDK exposes certain methods involving User logout, device link/User register, and device un-link, so that your Mobile App can perform these actions anywhere. With this capability, you can use your own buttons, interfaces, and views for these actions.

User Logout

To log out all active sessions for the current User, call:

Prototype:

- (void)logOut:(UIViewController*)parentViewController withSuccess:(successBlock)success withFailure:(failureBlock)failure;

Example:

[[WhiteLabelManager sharedClient] logOut:self withSuccess:^{

    } withFailure:^(NSString *errorMessage, NSString *errorCode) {

    }];

Note, with Authenticator SDK v2.2 and up, you can pass nil as the UIViewController to have UI elements removed (i.e. progress HUD stating "Logging Out").

In Authenticator SDK v2.3.2 and up, you can register a User using the following call and retrieve a NSError object if the call is unsuccessful. Please note that the "-logOut" call will be deprecated:

Prototype:

- (void)logOutWithViewController:(UIViewController*)parentViewController withCompletion:(completion)completion;

Example:

[[WhiteLabelManager sharedClient] logOutWithViewController:self withCompletion:^(NSError *error) {
    if(error != nil)
    {
            NSLog(@"error: %@", error);
    }
    else
    {
            //Successful
    }
    }];

Check Active Sessions

use this call to check for any active sessions. It will return true when there is an active session and false when there are no active sessions:

Prototype:

- (BOOL)checkActiveSessions;

Example:

[[WhiteLabelManager sharedClient] checkForActiveSessions];

In LaunchKey v2.2.1 and up, you can add the following observer to know when the -checkActiveSessions call has completed, in order to call it again for the most up-to-date BOOL value:

activeSessionComplete

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(checkActiveSession) name:activeSessionComplete object:nil];

Once the -checkActiveSessions call has been completed, the selector method (checkActiveSession in this example) will be called:

-(void)checkActiveSession
{

        // This will be called once checkActiveSessions has completed

}

In LaunchKey v2.2.2 and up, you can use the same observer and check the object passed back to receive the most up-to-date "YES" or "NO" value for -checkActiveSessions:

Example:

[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(checkActiveSessions:) name:activeSessionComplete object:nil];

Once the -checkActiveSessions call has been completed, the selector method (checkActiveSession in this example) will be called:

-(void)checkActiveSessions:(NSNotification*)notification
{

        // This will be called checkActiveSessions has completed, with a "YES" or "NO" NSString passed in the object of the NSNotification

        NSString *notificationString = [notification object];

        if([notificationString isEqualToString:@"YES"])
        {
                activeSession = YES;
        }
        else
        {
                activeSession = NO;
        }
}

Check Set Security Factors

In Authenticator SDK v2.2 and up, you can use this call to check which security factors are set. This call will return a NSArray in LaunchKey v2.2.1 and up (in Authenticator v2.2.0, this call returns a NSMutableArray) that lists the factor (pin_code, circle_code, geofence, bluetooth, and/or fingerprint), the type of factor (knowledge, inherence, possession) and whether the factor is active or not.

Prototype:

- (NSMutableArray*)getSecurityInfo;

Example:

[[WhiteLabelManager sharedClient] getSecurityInfo];

Error Handling (v2.2+)

With Authenticator SDK v2.2 and up, error handling has been improved for implementers. When interacting with the Launchkey APIs, an error message and error code (both NSStrings) are returned in the failure callback if there was an error. A type of error is now also included with the callback. Here's a comprehensive list of all error types:

  • NoInternetConnectivityError: Error representing the obvious lack of Internet connectivity on the device. This will allow the implementing app to either make extra connectivity checks and then try again, or notify the user of the current connectivity conditions
  • DeviceNotLinkedError: Error returned when the device is required to be linked before performing the requested action
  • InvalidLinkingCodeError: Error returned when attempting to link the device with an incorrect or expired linking code via registerUser. Keep in mind that the linking code will not make sense to the directory involved if the Authenticator SDK key is wrong, so always double check the Authenticator SDK key matches the one given by Dashboard
  • ExpiredAuthRequestError: Error returned when the Auth Request the user is attempting to respond to has already expired
  • DeviceNotFoundError: Error returned when attempting to unlink a device that does not exist. This could also happen when attempting to unlink a device that has already been unlinked
  • RequestArgumentError: Error returned when an operation requires a specific argument either by the implementer or even internally in very uncommon conditions

Done

The Authenticator SDK has now been configured and added to your iOS project. The final step is to integrate the LaunchKey Platform API within your Application using one of the SDKs.

User Contributed

LaunchKey links to user contributed code as a resource to its community. LaunchKey does not in any way guarantee or warrant the quality and security of these code bases. User contributed code is supported by the creators. If you do find a link from the site to user contributed code that is malicious or inappropriate in any way, please report that link to LaunchKey immediately and we will investigate the claim. Submit any issue to LaunchKey support at https://launchkey.com./support. ×