FronteggStoreOptions overview
This guide will discuss the various capbilities within the FronteggStoreOptions
plugin which is exposed in all client-side SDKs under </FronteggProvider>
in the React SDK, FronteggAppModule
in the Angular SDK or Frontegg
in Vue SDK. It needs to be passed to the providers at AuthOptions
and all the attributes that are discussed below can be found under the @frontegg
folder in your node_modules
.
keepSessionAlive
keepSessionAlive?: boolean
- this attribute is set to false
by default and should be set to true
if you would like the user's access token (JWT) to get refreshed automatically behind the scenes. User's token will be refreshed either via /refresh
request (embedded login) or /oauth/token
request (hosted login), just before the JWT expires. For example, if the JWT is set to 5 minutes, it will be refreshed every 4 minites or so and the user will not get logged out from the application, unless [session management] restrictions are being configured. If the attribute is not passed, or passed as false
, the user will be logged out at the moment their JWT expires.
disableSilentRefresh
disableSilentRefresh?: boolean
- by default, Frontegg's hosted login maintains an fe_refresh
cookie in order to maintain a frictionless user experience on page refreshes for example. The usage of this cookie may be limiting in certain cases when your infrastructure forces domain mismatches between your application and the domain of the cookie. In such cases, it is recommended passing this attribute as true
, which will resort to using OAuth protocol only, without relying on fe_refresh
cookie. Note that this may impact the end user experience.
enableSessionPerTenant
Prerequisites
Prerequisites
@frontegg/react@6.0.7
@frontegg/angular@6.7.0
@frontegg/vue@3.0.7\
enableSessionPerTenant?: boolean
- this attribute allows a user to be logged in to different accounts (tenants) in different tabs within the same browser. The default behavior for this attribute is false
as Frontegg relies on fe_refresh
cookie for authentication purposes, and by default this cookie is shared by all tabs in the browser. When this settings is set to true, the user can be logged in into several accounts (tenants) within the same browser tabs and actively work in them.
Session management
Session management
- Idle Session Timeout - the settings of
tenantId
on the JWT.\ - Force Re-login - uses the strictest policy of the user's accounts.\
- Maximum Concurrent Sessions - The
sid
is the same for all tabs that are open in the same browser and therefore this setting isn't directly affected.
allowedRedirectOrigins
& enforceRedirectToSameSite
allowedRedirectOrigins?: string[]
- when using Frontegg's embedded login you can pass enforceRedirectToSameSite
and allowedRedirectOrigins
flags to enhance your application's security and prevent attempts to generate potentially malicious redirects.
hostedLoginOptions
loadUserOnFirstLoad?: boolean
- this attribute allows to override the default logic for treating non authenticated users. Frontegg Hosted Login is aligned with OpenID Connect protocol and it is how Frontegg's hosted login authenticates the user. In most cases, the desired behavior is to redirect a non-authenticated user to the login page to complete authentication via [loginWithRedirect()
] method. If your application logic is different and you'd want to check whether the user is authenticated, but if they aren't you wouldn't necessarily want to redirect them to the login screen, you may use the loadUserOnFirstLoad
attribute and pass it as true
.
promptConsent
promptConsent?: boolean
- this attribute triggers user consent every time attempt to authenticate via social login. When it is passed as true
the social providers will trigger choosing every time choosing the email which the user would like to use. This may be useful when an end user has multiple social users on Google \ Microsoft \ GitHub and so on and need to select the correct one each time.