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:
Generate a RSA key pair of size 2048 bit. For example, you can use the following OpenSSL commands to generated the required key pair.
Send your public key, issuer name and key ID to your account representative or to support@sudoplatform.com. 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.
Implement
AuthenticationProvider
andAuthenticationInfo
interface defined in the User SDK to issue a signed JWT in the following format: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 support@sudoplatform.com.
The string encoded JWT should be returned by
toString()
(iOS) orencode()
(Android and TypeScript) method ofAuthenticationInfo
withtype
set toFSSO
. For more details, please refer to API Reference andLocalAuthenticationProvider
in our GitHub project.iOS example: LocalAuthenticationProvider
Android example: LocalAuthenticationProvider
TypeScript example: LocalAuthenticationProvider
Invoke
registerWithAuthenticationProvider
with yourAuthenticationProvider
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 federated sign in and you want Sudo Platform to manage your users. It uses Apple’s DeviceCheck token or Google Play Integrity token to ensure the registration request is coming from a legitimate 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.
On iOS, to obtain a DeviceCheck token:
Complete the iOS registration process by calling the register API:
On Android, to obtain a Google Play Integrity token:
Complete the Android registration process by calling the register API:
If you have enabled signing certificate validation for Android registrations then you must also complete the following steps:
In Google Play Console, navigate to Release -> Setup -> App signing and copy "SHA-256 certificate fingerprint" of your app.
In Sudo Platform Admin Console, navigate to Overview -> Settings and click on "Add" button to add the signing certificate fingerprint that you copied in the previous step.
The signing certificate fingerprint is owned by the admin user who created it. If the owner is deleted then the fingerprint will also be deleted for security reasons. If the owner is being deleted for off-boarding then make sure a new signing certificate's fingerprint is created by another admin user and re-signed app released before deleting the original owner.
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:
Log into the Sudo Platform Admin Console. A link and temporary login was emailed to you when your account was activated.
Go to Project Settings and locate the Test Registration Keys section.
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.
Registering with TEST authentication provider.
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.
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.
Last updated