Last updated

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

@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

  • 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.