Interface BackchannelLogoutOptions

Custom options to configure Back-Channel Logout on your application.

Hierarchy

  • BackchannelLogoutOptions

Properties

isLoggedOut?: false | ((req, config) => boolean | Promise<boolean>)

When backchannelLogout is enabled all requests that have a session will be checked for a previous Back-Channel logout. By default, this uses the sub and the sid (if available) from the session's ID token to look up a previous logout and logs the user out if one is found.

You can override this to implement your own Back-Channel Logout logic (See https://github.com/auth0/express-openid-connect/tree/master/examples/examples/backchannel-logout-custom-genid.js or https://github.com/auth0/express-openid-connect/tree/master/examples/examples/backchannel-logout-custom-query-store.js)

Type declaration

    • (req, config): boolean | Promise<boolean>
    • Parameters

      • req: Request<ParamsDictionary, any, any, ParsedQs, Record<string, any>>
      • config: ConfigParams

      Returns boolean | Promise<boolean>

onLogin?: false | ((req, config) => void | Promise<void>)

When backchannelLogout is enabled, upon successful login the SDK will remove any existing Back-Channel logout entries for the same sub, to prevent the user from being logged out by an old Back-Channel logout.

You can override this to implement your own Back-Channel Logout logic (See https://github.com/auth0/express-openid-connect/tree/master/examples/examples/backchannel-logout-custom-genid.js or https://github.com/auth0/express-openid-connect/tree/master/examples/examples/backchannel-logout-custom-query-store.js)

Type declaration

    • (req, config): void | Promise<void>
    • Parameters

      • req: Request<ParamsDictionary, any, any, ParsedQs, Record<string, any>>
      • config: ConfigParams

      Returns void | Promise<void>

onLogoutToken?: ((decodedToken, config) => void | Promise<void>)

Type declaration

store?: SessionStore<Pick<SessionStorePayload<Session>, "cookie">>

Used to store Back-Channel Logout entries, you can specify a separate store for this or just reuse SessionConfigParams.store if you are using one already.

The store should have get, set and destroy methods, making it compatible with express-session stores.