Redirects
Redirects are registered endpoints in Scalekit that control where users are directed during authentication flows. You must configure these endpoints in the Scalekit dashboard before they can be used.
All redirect URIs must be registered under Authentication settings in your Scalekit dashboard. This is a security requirement to prevent unauthorized redirects.
Understanding redirect types
Section titled “Understanding redirect types”Scalekit uses four types of redirect endpoints, each serving a specific purpose in the authentication flow:
Allowed callback URLs
Section titled “Allowed callback URLs”Purpose: Where users are sent after successful authentication to exchange authorization codes and retrieve profile information.
Example scenario: A user completes sign-in and Scalekit redirects them to https://yourapp.com/callback
where your application processes the authentication response.
Initiate login URL
Section titled “Initiate login URL”Purpose: When authentication does not initiate from your application, Scalekit redirects users back to your application’s login initiation endpoint. This endpoint should point to a route in your application that ultimately redirects users to Scalekit’s /authorize
endpoint.
Example scenarios:
-
Bookmarked login page: A user bookmarks your login page and visits it directly. Your application detects they’re not authenticated and redirects them to Scalekit’s authorization endpoint.
-
Organization invitation flow: A user clicks an invitation link to join an organization. Your application receives the invitation token and redirects the user to Scalekit’s authorization endpoint to complete the sign-up process.
-
IdP-initiated SSO: An administrator initiates single sign-on from their identity provider dashboard. The IdP redirects users to your application, which then redirects them to Scalekit’s authorization endpoint to complete authentication.
-
Session expiration: When a user’s session expires or they access a protected resource, they’re redirected to
https://yourapp.com/login
which then redirects to Scalekit’s authentication endpoint.
Post logout URL
Section titled “Post logout URL”Purpose: Where users are sent after successfully signing out of your application.
Example scenario: After logging out, users are redirected to https://yourapp.com/goodbye
to confirm their session has ended.
Back channel logout URL
Section titled “Back channel logout URL”Purpose: A secure endpoint that receives notifications whenever a user is logged out from Scalekit, regardless of how the logout was initiated — admin triggered, user initiated, or due to session policies like idle timeout.
Example scenario: When a user logs out from any application (user-initiated, admin-initiated, or due to session policies like idle timeout), Scalekit sends a logout notification to https://yourapp.com/logout
to suggest termination of the user’s session across all connected applications, ensuring coordinated logout for enhanced security.
Configure redirect URLs
Section titled “Configure redirect URLs”To configure your redirect URIs:
- Navigate to Authentication settings in your Scalekit dashboard
- Add your URIs following the validation rules below
- Save your configuration
URI validation rules
Section titled “URI validation rules”Your redirect URIs must meet specific requirements that vary between development and production environments:
Environment-specific requirements
Section titled “Environment-specific requirements”Validation rule | Development environment | Production environment |
---|---|---|
Supported schemes | http https | https |
localhost usage | Allowed | Not allowed |
Wildcard support (*) | Allowed | Not allowed |
Maximum URI length | 256 characters | 256 characters |
Query parameters yourapp.com/callback?query=value | Not allowed | Not allowed |
Fragment components
| Not allowed | Not allowed |
Use wildcards for development
Section titled “Use wildcards for development”Wildcards can simplify testing in development environments, but they must follow specific patterns:
Validation rule | Examples |
---|---|
Wildcards cannot be used as root-level domains | https://*.com https://*.acmecorp.com https://auth-*.acmecorp.com |
Only one wildcard character is allowed per URI | https://*.*.acmecorp.com https://*.acmecorp.com |
Wildcards must be in the hostname component only | https://acmecorp.*.com https://*.acmecorp.com |
Wildcards must be in the outermost subdomain | https://auth.*.acmecorp.com https://*.auth.acmecorp.com |