Options

Options #

optionsman

May your choices reflect your hopes, not your fears. – Nelson Mandela

The options for a AppKey application can be managed for a AppKey App in this tab. It includes the ability to manage the following features:

  • APP USER NAME LOGIN: whether the AppKey app also includes support for unique user names in addition to handles to identify users. User names can be used in lieu of handle for loging in.
  • ALLOW ANONYMOUS LOGIN: whether the AppKey app supports anonymous login.
  • ALLOW APPLE LOGIN: whether to enable Apple ID login.
  • ALLOW GOOGLE LOGIN: whether to enable Google Gmail login.

And these other features:

  • APP SIGNUP: whether application user onboarding is open or by invitation only.
  • HANDLE TYPE: whether application handles are email, phone, or both.
  • SET RELYING PARTY ID: set the WebAuthN FIDO2 relying party for the application passkey.
  • SET ANDROID APK ID: set the Android APK facet ID for Android support.
  • EMAIL EXTENSIONS: controls the return email address in emails sent to the user.

options

User Names #

Within the AppKey authentication system, email (or phone number) stands as the default handle mechanism, serving as the primary means for user identity verification even when using external onboarding mechanisms. Nonetheless, this system goes beyond email support and embraces the option for unique user names to identify users.

Once a user name is associated with a user, it can also serve as their handle for logging in. User names offer the advantage of being more memorable compared to emails, but more importantly, they aid in preserving user privacy concerning other users. Instead of sharing the email address of a user, connections can be established using their user names, safeguarding their identity and promoting a more discreet user interaction experience.

Anonymouse Login #

The AppKey authentication system extends its support to encompass anonymous login functionality. This proves immensely advantageous when onboarding users into an application without burdening them with the need to enter user-specific data. This approach allows an application to offer a minimal set of functionality initially, without necessitating formal sign-up. Subsequently, users can upgrade to fully qualified users with verified emails and/or user names at their discretion.

For anonymous users, the handle consistently follows the format ANON_ (e.g., ANON_209CAE69-102F-418D-9EFC-F096621F1188). Moreover, developers can conveniently track anonymous users through the USERS tab found within the Application Settings.

To activate the Anonymous Login feature, developers need only enable the Allow Anonymous Login switch, providing an effortless means to empower this functionality.

Allow Apple Login #

applesignin

It might seem surprising that the AppKey authentication system includes support for Apple Login. However, social login has become a popular choice for application onboarding, so we decided it was worth integrating. Beyond that, social login itself is evolving, moving away from traditional email/password mechanisms toward passkeys. This shift aligns well with AppKey’s goals, making the integration a natural fit.

Beyond traditional email passkey authentication, the AppKey authentication system also supports Apple Id Sign In. This feature streamlines the onboarding process for iOS applications, minimizing user sign-up hurdles. This functionality is fully integrated into the AppKey authentication REST API (similar to anonymous login), offering a unified JWT interface for this social login feature.

Should a developer choose to enable Apple Login, he/she will need to supply the Apple Bundle ID for the iOS Application. If the application needs to support both login from an iOS device and a web page, the developer may need to provide a list of Apple Bundle IDs that are comma seperated.

Note: Apple Id Sign In is operational only in release mode, and not in development mode.

Allow Google Login #

googlesignin

AppKey also facilitates the Google Login social protocol. This is akin to Apple Id Sign In but utilizes a GMAIL account rather than an Apple Id. You can find a comprehensive description of the Google Authentication protocol here. To activate Google Login within the client application, the developer must furnish the Google Client ID for the application. Like the Apple Bundle ID, AppKey supports multiple Google Client IDs that are comma seperated.

Just like Apple Id Sign In, the Google Login social protocol operates solely in release mode, not in development mode.

Additional Options #

options2

App Signup #

AppKey offers two types of user onboarding experiences: open onboarding, where any user can sign up for the app, or onboarding that is limited to invitation only.

In the invitation-only scenario, users can join the application only if their handle has been invited by the developer through the AppKey Portal. This feature is essential when it’s necessary to control and regulate who can access the application.

The invitation process works by sending an email or message to the invited user’s handle, usually an email address, notifying them of their invitation. The user can then complete the sign-up process using two-factor verification on their handle.

Handle Type #

AppKey supports two types of handles that uniquely identify a user: email or phone. Each handle must be unique to the user and verified through a six-digit code sent for two-factor authentication. Once this verification process is complete, the handle is linked to the user’s passkey on their device for the specific application. Additionally, AppKey allows the use of both email and phone interchangeably, referred to as the “both” option.

Set Relying Party Id #

The AppKey passkey implementation is built on WebAuthn, a protocol that relies on the concept of a relying party—the URL associated with the application, as defined in the AppKey portal.

The Relying Party (RP) is the entity whose web application uses WebAuthn to handle user registration and authentication. The RP sets the options for WebAuthn during registration and authentication ceremonies, tailoring them to enhance security, build trust in the authenticator, and streamline the user experience. It is also the RP’s responsibility to validate responses from the WebAuthn API and decide whether to trust the authenticator before registering a passkey.

By default, if no relying party is specified for an AppKey app, the RP is set to https://appkey.io. In this case, passkey usernames take the form email@domain.com(app-id), where app-id is the identifier for the app. This format is useful for demos, as it ensures unique usernames across applications.

If a developer specifies a custom RP, such as https://appdomain.com, the passkey username simplifies to email@domain.com. The app-id suffix is omitted, as the custom RP removes the need for disambiguation. This approach balances flexibility for developers with clarity and consistency for end-users.

Email Extensions #

The AppKey Email Extensions section within the Options tab of the AppKey Portal serves the purpose of altering the return email address used to verify a user’s email authenticity during the signup process. In AppKey, the default email is noreply@cosync.io. However, it is common for developers to prefer a customized address like noreply@xyzsoft.com, especially if they work for XYZSoft.

Configuring this override is a straightforward process. Firstly, the developer requires a SendGrid account and a SendGrid API key. Secondly, they need to provide a reply email (e.g., noreply@xyzsoft.com) and verify that this email sender identity is duly registered with their SendGrid account.

extension