You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -52,7 +50,16 @@ curl --location --request PUT '^{coreInjector_uri_without_quotes}/recipe/multite
52
50
- The above command will create (or update) an app with the appId of `app1`.
53
51
- It will also create a default tenant for this app with the tenant ID of `public` (i.e. the default tenantId)
54
52
- You can set various core configs for this app (see the config.yaml / docker env var options for your core). The core configs for a new app will inherit from the the configs provided in the config.yaml / docker env (or our edit config dashboard for managed service).
55
-
- By default, all the login methods are enabled for a new app (specifically, the `public` tenant of the new app), but you can pass in `false` to any of the login methods specified above to disable them.
53
+
- By default, all the login methods are enabled for a new app (specifically, the `public` tenant of the new app), but you can pass in `firstFactors` input to specifically enable selected login methods.
54
+
55
+
The built-in Factor IDs that can be used for `firstFactors` are:
56
+
- Email password auth: `emailpassword`
57
+
- Social login / enterprise SSO auth: `thirdparty`
58
+
- Passwordless:
59
+
- With email OTP: `otp-email`
60
+
- With SMS OTP: `otp-phone`
61
+
- With email magic link: `link-email`
62
+
- With SMS magic link: `link-phone`
56
63
57
64
:::important
58
65
Even if a login method is enabled for a tenant, you will still require to initialise the right recipe on the backend for sign up / in to be possible with that login method. For example, if for a tenant, you have enabled the passwordless login method, but don't use the passwordless (or a combination recipe that has passwordless) on the backend, then end users will not be able to sign up / in using the passwordless APIs cause those APIs won't be exposed via our backend SDK's middleware.
@@ -51,7 +49,16 @@ curl --location --request PUT '^{coreInjector_uri_without_quotes}/recipe/multite
51
49
- The above command will create (or update) an app with the appId of `app1`.
52
50
- It will also create a default tenant for this app with the tenant ID of `public` (i.e. the default tenantId)
53
51
- You can set various core configs for this app (see the config.yaml / docker env var options for your core). The core configs for a new app will inherit from the the configs provided in the config.yaml / docker env (or our edit config dashboard for managed service).
54
-
- By default, all the login methods are enabled for a new app (specifically, the `public` tenant of the new app), but you can pass in `false` to any of the login methods specified above to disable them.
52
+
- By default, all the login methods are enabled for a new app (specifically, the `public` tenant of the new app), but you can pass in `firstFactors` input to specifically enable selected login methods.
53
+
54
+
The built-in Factor IDs that can be used for `firstFactors` are:
55
+
- Email password auth: `emailpassword`
56
+
- Social login / enterprise SSO auth: `thirdparty`
57
+
- Passwordless:
58
+
- With email OTP: `otp-email`
59
+
- With SMS OTP: `otp-phone`
60
+
- With email magic link: `link-email`
61
+
- With SMS magic link: `link-phone`
55
62
56
63
:::important
57
64
Even if a login method is enabled for a tenant, you will still require to initialise the right recipe on the backend for sign up / in to be possible with that login method. For example, if for a tenant, you have enabled the passwordless login method, but don't use the passwordless (or a combination recipe that has passwordless) on the backend, then end users will not be able to sign up / in using the passwordless APIs cause those APIs won't be exposed via our backend SDK's middleware.
0 commit comments