Search…
Registration
In order to access various services in Sudo Platform, you must first register a new user and sign in using the User SDK.

OIDC Federated Sign In

If you are using an external identity provider that supports OpenID Connect (OIDC) standard with Sudo Platform then an explicit user registration is not required. An existing user of your identity provider can perform a federated sign in to start using various services provided by Sudo Platform. For more details, please refer to Authentication section.

Custom Federated Sign In

The OIDC standard based Federated Sign In is the preferred method to integrate your external identity provider with Sudo Platform however, if you prefer a programmatic method to user sign in, this can be achieved by implementing a Custom Federated Sign In by providing a a signed JWT to the User SDK.
To register a new user based on the custom federated sign in:
  1. 1.
    Generate a RSA key pair of size 2048 bit. For example, you can use the following OpenSSL commands to generated the required key pair.
    1
    openssl genrsa -out key.pem 2048
    2
    openssl rsa -in key.pem -outform PEM -pubout -out public.pem -RSAPublicKey_out
    Copied!
  2. 2.
    Send your public key, issuer name and key ID to your account representative or to [email protected]. The issuer name and key ID is used to uniquely identify the public key that we will use to validate the authentication token generated by you.
  3. 3.
    Implement AuthenticationProvider and AuthenticationInfo interface defined in the User SDK to issue a signed JWT in the following format:
    1
    // Header
    2
    {
    3
    "alg": "RS256",
    4
    "kid": "<key_id>"
    5
    }
    6
    7
    // Payload
    8
    {
    9
    "aud": "identity-service",
    10
    "sub": "<user_id>",
    11
    "jti": "98BCA65D-CAA1-4E91-A23F-FAB819C7C53D",
    12
    "iss": "<issuer_name>",
    13
    "iat": 1608102082,
    14
    "exp": 1608105682
    15
    }
    16
    // Signature.
    Copied!
    • The digital signature algorithm used to sign the JWT must be RSA with SHA-256 ("RS256").
    • The key ID ("kid") must uniquely match the key ID that you provided in the previous step.
    • The audience ("aud") must always be "identity-service".
    • The subject (“sub”) denotes the unique identifier of the identity being federated. The username of the newly created Sudo Platform user will be set to “sub” contained in the token.
    • The token ID ("jti") should be a unique ID such as UUID.
    • The issuer (“iss”) denotes the issuer of the token, i.e. the external identity provider. This must uniquely match the issuer name that you provided in the previous step.
    • The issued at time ("iss") is milliseconds since epoch representation of when the token was issued.
    • The expiry ("exp") is milliseconds since epoch representation of when the token should expire. This time should be short but long enough to allow for the time it will take for the client to submit the token to Sudo Platform.
    • Optionally any number of custom attributes can be added and if you need those attributes to be persisted in the user record then please contact your account representative or send an email to [email protected].
    The string encoded JWT should be returned by toString() (iOS) or encode() (Android and TypeScript) method of AuthenticationInfo with type set to FSSO. For more details, please refer to API Reference and LocalAuthenticationProvider in our GitHub project.
  4. 4.
    Invoke registerWithAuthenticationProvider with your AuthenticationProvider implementation as an input.

Sign in Key Registration

Sign in key registration is used to create a new user if you don't have users in a registry that supports Open ID Connect and you want Sudo Platform to manage your users. It uses Apple’s DeviceCheck token or Google SafetyNet Attestation validation to ensure the registration request is coming from a legitimate iOS or Android device.
During the registration, the client creates a private/public key pair and the public key is stored in the Sudo Platform. The private key is used to digitally sign a token during subsequent sign in and the token is validated using the previously registered public key.
Obtain a DeviceCheck token or SafetyNet attestation result:
Swift
Kotlin
1
// Obtain a DeviceCheck token from iOS via AppDelegate interface.
2
import DeviceCheck
3
4
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
5
let currentDevice = DCDevice.current
6
if currentDevice.isSupported {
7
currentDevice.generateToken(completionHandler: { (data, error) in
8
if let error = error {
9
// Handle error.
10
}
11
12
let deviceCheckToken = data
13
})
14
}
15
return true
16
}
Copied!
1
val deviceId = Secure.getString(
2
this.appContext.contentResolver,
3
Secure.ANDROID_ID
4
)
5
6
SafetyNet.getClient(this.appContext).attest(deviceId.toByteArray(), apiKey)
7
.addOnSuccessListener {
8
// Successfully obtained SafetyNet attestation result.
9
val attestationResult = it.jwsResult)
10
}
11
.addOnFailureListener {
12
// Handler errors.
13
}
Copied!
Complete the registration process by calling the register API:
Swift
Kotlin
1
do {
2
try client.registerWithDeviceCheck(token: deviceCheckToken,
3
buildType: "release",
4
vendorId: UIDevice.current.identifierForVendor,
5
registrationId: UUID().uuidString) { (result) in
6
switch result {
7
case .success(let uid):
8
// Returned uid is the unique ID of the newly created user.
9
case .failure(let cause):
10
// Handle error. A failure result may be returned if the backend is unable
11
// perform the registration due to availability or security issues.
12
}
13
}
14
} catch let error {
15
// Handle error. An error might be thrown for unrecoverable circumstances arising
16
// from programmatic error or configuration error. For example, if the keychain
17
// access entitlement is not set up correctly, register API is getting called
18
// multiple times simultaneously or basic system resources are unavailable.
19
}
Copied!
1
CoroutineScope(Dispatchers.IO).launch {
2
try {
3
client.registerWithSafetyNetAttestation(attestationResult, deviceId, UUID.randomUUID().toString())
4
// Registration was successful.
5
} catch (e: RegisterException) {
6
//Handle error.
7
}
8
}
Copied!

Test Registration Keys

To bypass various security and entitlement restrictions for running integration tests, you can use test registration keys. Use test registration keys when other registration techniques are unavailable, or when writing integration tests.
A test registration key allows you to register a device multiple times. Additionally, you can manipulate the registered user's entitlements so that more resources can be provisioned than what is allowed by default.

Generate a Test Registration Key

Test registration keys can be generated and downloaded in the Admin Console. Keys are specific to the logged-in Admin Console user and the project (e.g. dev, qa, prod). A generated key can only be downloaded once. If you cannot locate a previously generated key, you will need to revoke they key and generate a new one.
To download a test registration key:
  1. 1.
    Log into the Sudo Platform Admin Console. A link and temporary login was emailed to you when your account was activated.
  2. 2.
    Go to Project Settings and locate the Test Registration Keys section.
  3. 3.
    Click on Generate Test Registration Key and follow the prompt to download the newly generated key.
A PEM encoded test registration key can be passed to the test via a number of ways, e.g. via environment variable, temporary file etc. Regardless of the mechanism chosen, keep the key data secure and do not include it in your app build published to end users.
We don't prescribe the method in which to pass the test registration key and key ID as the approach will likely vary depending on whether you are writing integration tests vs setting up CI, etc.
For an example approach, please take a look at the open source iOS sample app and the open source Android sample app on Github.
Initialize a TEST authentication provider.
Swift
Kotlin
TypeScript
1
// "testKey" is PEM encoded TEST key obtained from the previous step. "name" parameter should be unique for each test suite.
2
// "KeyManager" instance should use a unique namesapce as well so resetting it does not cause other keys to be removed.
3
do {
4
let testAuthenticationProvider = try TESTAuthenticationProvider(
5
name: "mytest",
6
key: testKey,
7
keyId: "Key ID of your TEST key from the admin console.",
8
keyMananger: SudoKeyManagerImpl(
9
serviceName: "com.sudoplatform.appservicename",
10
keyTag: "com.sudoplatform",
11
namespace: "mytest"
12
)
13
)
14
} catch let error {
15
// Handle error. An error might be thrown for unrecoverable circumstances arising
16
// from programmatic error or configuration error. For example, if the keychain
17
// access entitlement is not set up correctly or basic system resources are
18
// unavailable.
19
}
Copied!
1
// "name" parameter should be unique for each test suite.
2
// "privateKey" and "keyId" are PEM encoded TEST registration key and key ID obtained from
3
// the previous step.
4
val keyManager = KeyManagerFactory(appContext).createAndroidKeyManager()
5
// Note: The public key is optional as it can be derived from the private key. However, on
6
// Android API 23 this is not possible due to limitations in Java security provider so
7
// when running tests with Android API 23 emulator generate the public key using
8
// "openssl rsa -in <private_key> -outform PEM -RSAPublicKey_out" and pass the resulting
9
// public key as publicKey parameter.
10
val testAuthenticationProvider = TESTAuthenticationProvider("mytest", privateKey, null, keyManager, keyId)
Copied!
1
// "name" parameter should be unique for each test suite.
2
// "privateKey" and "keyId" are PEM encoded TEST registration key and key ID obtained from
3
// the previous step.
4
const testAuthenticationProvider = new TESTAuthenticationProvider(
5
'mytest',
6
privateKey,
7
keyId,
8
)
Copied!
Registering with TEST authentication provider.
Swift
Kotlin
TypeScript
1
do {
2
try client.registerWithAuthenticationProvider(authenticationProvider: auttestAuthenticationProviderhProvider, registrationId: UUID().uuidString) { (result) in
3
switch result {
4
case .success:
5
// Registration successful.
6
case .failure(let cause):
7
// Handle error. A failure result may be returned if the backend is unable
8
// perform the registration due to availability or security issues.
9
}
10
}
11
} catch let error {
12
// Handle error. An error might be thrown for unrecoverable circumstances arising
13
// from programmatic error or configuration error. For example, if the keychain
14
// access entitlement is not set up correctly, register API is getting called
15
// multiple times simultaneously or basic system resources are unavailable.
16
}
Copied!
1
CoroutineScope(Dispatchers.IO).launch {
2
try {
3
client.registerWithAuthenticationProvider(
4
testAuthenticationProvider,
5
UUID.randomUUID().toString()
6
)
7
// Registration was successful.
8
} catch (e: RegisterException) {
9
// Handle error. A failure result may be returned if the backend is unable
10
// to perform the registration due to availability or security issues.
11
}
12
}
Copied!
1
try {
2
await client.registerWithAuthenticationProvider(
3
testAuthenticationProvider,
4
uuid.v4(),
5
)
6
// Registration was successful.
7
} catch (err) {
8
// Handle error. A failure result may be returned if the backend is unable
9
// to perform the registration due to availability or security issues.
10
}
Copied!
See it in action. Be sure to take a look at the iOS and Android sample apps on GitHub, which demonstrate how to use a test registration key.

De-registration (aka Account Deletion)

De-registering the user deletes the user and all associated resources from Sudo Platform.
If you are using federated sign-in and you wish to delete the user do not call the deregister API. Use the appropriate API provided by your identity provider instead.
As with most platform APIs, de-registering requires the client to be signed in. Please see Authentication section for more details.
Swift
Kotlin
TypeScript
1
do {
2
try client.deregister { (result) in
3
switch result {
4
case .success:
5
// User de-registered successfully.
6
case .failure(let cause):
7
// Handle error. A failure result may be returned if the backend is unable
8
// perform the de-registration due to availability or security issues.
9
}
10
}
11
} catch let error {
12
// Handle error. An error might be thrown for unrecoverable circumstances arising
13
// from programmatic error or configuration error. For example, if the keychain
14
// access entitlement is not set up correctly or basic system resources are
15
// unavailable.
16
}
Copied!
1
CoroutineScope(Dispatchers.IO).launch {
2
try {
3
client.deregister()
4
// User de-registered successfully.
5
} catch (e: DeregisterException) {
6
// Handle error. A failure result may be returned if the backend is unable
7
// to perform the de-registration due to availability or security issues.
8
}
9
}
Copied!
1
try {
2
await client.deregister()
3
// User de-registered successfully.
4
} catch (err) {
5
// Handle error. A failure result may be returned if the backend is unable
6
// to perform the de-registration due to availability or security issues.
7
}
Copied!

Resetting Client State

You can reset the internal state information maintained by SudoUserClient by calling reset API.
Resetting the client state will cause all persistent data to be lost including sign in key, authentication tokens and username. You would no longer be able to sign in as the previously registered user so a new user must be registered.
Swift
Kotlin
TypeScript
1
do {
2
try client.reset()
3
} catch let error {
4
// Handle error. An error might be thrown for unrecoverable circumstances arising
5
// from programmatic error or configuration error. For example, if the keychain
6
// access entitlement is not set up correctly or basic system resources are
7
// unavailable.
8
}
Copied!
1
client.reset()
Copied!
1
client.reset()
Copied!
Last modified 1d ago