Below are the list of settings that you can customize for your project. These affect all aspects of your project including authentication methods, flows and overall security configuration. These can be customized on Descope Console>Settings>Project.
Project name of your project. Project name is autogenerated at the time of project creation and can be set to any string. This has no other applicability other than the display in the left pane. All internal configuration and API calls use Project ID. Project ID cannot be modified.
The App URL is the URL which your application resides on. This is used for items within Descope including custom domains and callback URLs within social applications when using your own provider.
An extensive guide covering the App URL and configuring custom domains can be found here.
List of approved domains that allowed for redirect and verification URLs for different authentication methods. If the value is left empty, a malicious actor can generate malicious redirect links if your application has a vulnerability. We strongly suggest setting this parameter to your application domain before moving the application to production.
This checkbox restricts new user sign-up. With this setting enabled, new users are only allowed with an invite (Descope Console>Users) or by using the organization configured SSO method. Please see the Restrict Self-Registration Sign-Ups guide for further implementation instructions.
This is where you will configure details of the invitations sent when you invite a user to your application.
- The connector is whether the invitation email is sent with the Descope email connector or your configured SendGrid or SMTP connector.
- The template is where you can add a template to customize your invite email when using a connector. When using the Descope connector, custom templates are unavailable.
- The Redirect URL is the URL which the user will receive in their invite email.
- Add a Magic Link token to the invitation email - when this checkbox is selected, the user will also receive a magic link within the invitation email. Once selected, you can also set the Invite Token Expiration. See this guide for details on this implementation.
Note: Further information around the user invitation can be found within this article.
_Note: Session management can also be overridden at a tenant level. More information about tenant level session management can be found here.
This value sets the validity period for refresh token. For more details please read session management article.
When enabled, every time the user refreshes their session token (using the refresh token) - the refresh token is also updated to a new one. This method is considered a more secure approach.
Note: Configuring Refresh Token Rotation is a pro-tier feature. Learn more about upgrading your tier within our pricing overview.
Expiry time of the session token, used for accessing the application's resources. Value needs to be at least 3 minutes and can't be longer than the Refresh Token Timeout.
Expiry time for the Step Up token, after which the step up token will not be valid, and the user will automatically go back to the Session token.
Expiry time of the access key session token. Value needs to be at least 3 minutes and can't be longer than a month.
Enable session inactivity detection within
the session management configuration. Once enabled, Descope will detect idle sessions and close them on behalf
of the user, to protect sensitive information.
After enabling this configuration, you can configure the
Inactivity timeout per your desired configuration.
This timeout will determine the amount of time until Descope will detect and close the idle sessions.
Descope enables security and complete session management with its SDKs. Descope service can deliver the session and refresh token in two different ways to your application:
When the tokens are delivered as cookies, the Descope SDKs automatically save them using the set custom domain. With this setup, the browser will send the cookies to your application server with every request for session validation.Review the Custom Domain tutorial or the Testing Locally with Tokens Stored in Cookies guide for details on configuring the
Manage in Cookies.The
domain configurations are covered within this knowledge base guide.
If you are testing your application, then you can choose to deliver cookies in the response body and handle them in your application logic.