Project Settings
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.
Multi-Regional Support
Descope supports multi-region data residency. The current supported regions are US and EU. For GDPR compliancy, you can store and process user data within the EU region. If you are interested in EU data residency, reach out to Descope support.
Note
Once you have selected a region during the project creation, Descope will store all project and user data within that region, which cannot be moved between regions later.
Settings Summary
General
Project name
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.
Region
Descope supports multi-region deployments. The region is selected during the project creation and cannot be changed after the project has been created.
Environment Settings
When you create a new project, you can
provide the project with a name and choose whether it is production or non-production. You can later change
whether the project is production or non-production from the Project Settings
page within the console. Note that selecting production or non-production does not effect the features within
the project. This is an internal identifier for Descope to see which projects are marked as production.
App URL and Configure Custom Domain
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.
Security
Approved Domains
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.
Sign Up
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.
User Invitation
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.
Session Management
Note
Session management can also be overridden at a tenant level. More information about tenant level session management can be found here.
Token Expiration
Refresh Token Timeout
This value sets the validity period for refresh token. For more details please read [session management[(/session-validation) article.
Refresh Token Rotation
Note
Configuring Refresh Token Rotation is a pro-tier feature. Learn more about upgrading your tier within our pricing overview.
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.
To learn more about this, visit our Refresh Token Rotation guide.
Session Token Timeout
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.
Step Up 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.
Trusted Device Token Timeout
Trusted device feature can be configured to have customizable duration. This field sets expiry time for trusted device token, after which this token will not be valid. Default value is set to 365 days.
Access Key Session Token Timeout
Expiry time of the access key session token. Value needs to be at least 3 minutes and can't be longer than a month.
Session Inactivity
You can enable session inactivity detection by checking the box for Enable session inactivity detection within the session
management configuration. When session inactivity detection is enabled, Descope identifies these idle sessions and automatically
terminates them to safeguard sensitive information. This functionality is crucial for maintaining security and managing system
resources efficiently.
An idle session occurs when there is no user activity within the system for a specified duration, as set in the Inactivity Timeout.
After enabling session inactivity detection, the Inactivity Timeout is configurable. This timeout will determine the amount of time
until Descope detects and closes the idle sessions.
Token Response Method
Descope enables security and complete [session management[(/session-validation) with its SDKs. Descope service can deliver the session and refresh token in two different ways to your application:
Manage in cookies
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 sameSite and domain configurations are covered within this knowledge base guide.
Manage in response body
If you are testing your application, then you can choose to deliver cookies in the response body and handle them in your application logic.
Sign Ups and User invitations
Within this area, you can configure the project's behavior around Sign-Ups and User Invitations. For further details about these configurations, review our dedicated guides around inviting users and self-registration.
Test Users
Within this area, you can configure a regex to match provided email addresses during sign-up-or-in; when the email matches this regex, the user will be created as a test user. For detailed documentation on how to utilize this feature, see the Dynamic Test Users Configuration.
Project Management
You can manage projects within this area. For details, review our dedicated guide on Project Management.