​

Recovering Sessions

By default, the SDK will require users to sign in everytime the app is closed completely. This is because, by default, we do not write the session wallet information (e.g. private keys) to any form of persistent storage for user security.

However, on select platforms, we have integrated with the platform’s native secure storage offering.

If you enable StoreSessionPrivateKeyInSecureStorage in your SequenceConfig ScriptableObject, we will automatically store the session wallet information for you (on supported platforms) and expose the ability to attempt to recover the session in SequenceLogin. The default LoginPanel will automatically handle the UI flow for this as well (see Authentication). If the platform is not supported, this flag will have no effect.

See below the supported platforms and to learn about the platform’s secure storage solution - it is important to understand the basics of how these systems work and think carefully about the security implications of storing private keys (or any secret for that matter) in persistent storage.

​

iOS

On iOS, we leverage the iOS Keychain.

​

MacOS

On MacOS, we leverage the MacOS Keychain.

​

Windows

On Windows PCs, we leverage the Crypto: Next Generation - Data Protection API (CNG DPAPI)

​

Web

On Web builds, we leverage IndexedDB via PlayerPrefs.

​

Android

On Android builds, we leverage the Android Keystore.

Our Keystore plugin for Unity (included in the SDK) requires a Custom Main Gradle Template. Please navigate to your Project Settings, then under Player > Publishing Settings enable Custom Main Gradle Template. This will create a file Assets/Plugins/Android/mainTemplate.gradle (or similar, the editor will show you the path) if you don’t have one already. Here is an example mainTemplate.gradle file; please copy/paste this (or incorporate into your existing file).

apply plugin: 'com.android.library'
**APPLY_PLUGINS**

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    implementation 'androidx.security:security-crypto:1.1.0-alpha03'

**DEPS**}

android {
    compileSdkVersion **APIVERSION**
    buildToolsVersion '**BUILDTOOLS**'

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    defaultConfig {
        minSdkVersion **MINSDKVERSION**
        targetSdkVersion **TARGETSDKVERSION**
        ndk {
            abiFilters **ABIFILTERS**
        }
        versionCode **VERSIONCODE**
        versionName '**VERSIONNAME**'
        consumerProguardFiles 'proguard-unity.txt'**USER_PROGUARD**
    }

    lintOptions {
        abortOnError false
    }

    aaptOptions {
        noCompress = **BUILTIN_NOCOMPRESS** + unityStreamingAssets.tokenize(', ')
        ignoreAssetsPattern = "!.svn:!.git:!.ds_store:!*.scc:.*:!CVS:!thumbs.db:!picasa.ini:!*~"
    }**PACKAGING_OPTIONS**
}**REPOSITORIES**
**IL_CPP_BUILD_SETUP**
**SOURCE_BUILD_SETUP**
**EXTERNAL_SOURCES**

Our Keystore plugin also requires a Custom Gradle Properties Template. Again, navigate to your Project Settings, then under Player > Publishing Settings enable Custom Gradle Properties Template. This will create a file Assets/Plugins/Android/gradleTemplate.properties (or similar, the editor will show you the path) if you don’t have one already. Here is an example gradleTemplate.properties file; please copy/paste this (or incorporate into your existing file).

org.gradle.jvmargs=-Xmx**JVM_HEAP_SIZE**M
org.gradle.parallel=true
android.enableJetifier=true
android.useAndroidX=true
unityStreamingAssets=**STREAMING_ASSETS**
**ADDITIONAL_PROPERTIES**

android.enableR8=**MINIFY_WITH_R_EIGHT**

​

Editor

In the editor, we use PlayerPrefs for private key storage. You will also need to enable ‘EditorStoreSessionPrivateKeyInSecureStorage’ in SequenceConfig in order to use secure storage and recover sessions from within the editor. This separate flag makes it easier for you to test both flows without modifying the behaviour of your builds. Secure storage in the editor is for development purposes only and should not be considered secure for long-term storage.