Refresh session token

[Faiyyaz]

Hey,

if you take an example of passport authentication, then what we can do there is we can assign two tokens i.e. access token and refresh token. The access token has a shorter life compared to refresh token and then when access token is expired, we pass refresh token to a api and get new access token instead of logging out the user.

So do we have the same mechanism in keystonejs? Because I cannot find anything in the document related to it.

Thanks!

[unrevised6419]

Myself I've been working only with @keystone-6.

The Keystone does not use an OAuth/OpenID mechanism.
Instead, it uses a classic cookie approach to track user sessions.

If the user enters the correct username and password, KS will generate a session cookie encrypted with a server secret using @hapi/iron and save it in the user's browser cookie.

That cookie is valid until it expires. When it expires, the user has to log in again.

If you want to see more technical details, you can look into the stateless session code.

keystone/packages/core/src/session/index.ts

Lines 62 to 125 in bd33f07

	export function statelessSessions<Session> ({
	secret = randomBytes(32).toString('base64url'),
	maxAge = 60 * 60 * 8, // 8 hours,
	cookieName = 'keystonejs-session',
	path = '/',
	secure = process.env.NODE_ENV === 'production',
	ironOptions = Iron.defaults,
	domain,
	sameSite = 'lax',
	}: StatelessSessionsOptions = {}): SessionStrategy<Session, any> {
	// atleast 192-bit in base64
	if (secret.length < 32) {
	throw new Error('The session secret must be at least 32 characters long')
	}
	return {
	async get ({ context }) {
	if (!context?.req) return
	const cookies = cookie.parse(context.req.headers.cookie || '')
	const bearer = context.req.headers.authorization?.replace('Bearer ', '')
	const token = bearer || cookies[cookieName]
	if (!token) return
	try {
	return await Iron.unseal(token, secret, ironOptions)
	} catch (err) {}
	},
	async end ({ context }) {
	if (!context?.res) return
	context.res.setHeader(
	'Set-Cookie',
	cookie.serialize(cookieName, '', {
	maxAge: 0,
	expires: new Date(),
	httpOnly: true,
	secure,
	path,
	sameSite,
	domain,
	})
	)
	},
	async start ({ context, data }) {
	if (!context?.res) return
	const sealedData = await Iron.seal(data, secret, { ...ironOptions, ttl: maxAge * 1000 })
	context.res.setHeader(
	'Set-Cookie',
	cookie.serialize(cookieName, sealedData, {
	maxAge,
	expires: new Date(Date.now() + maxAge * 1000),
	httpOnly: true,
	secure,
	path,
	sameSite,
	domain,
	})
	)
	return sealedData
	},
	}
	}

The auth module adds some more code to the session getter.

keystone/packages/auth/src/index.ts

Lines 161 to 192 in bd33f07

	// this strategy wraps the existing session strategy,
	// and injects the requested session.data before returning
	function authSessionStrategy<Session extends AuthSession> (
	_sessionStrategy: SessionStrategy<Session>
	): SessionStrategy<Session> {
	const { get, ...sessionStrategy } = _sessionStrategy
	return {
	...sessionStrategy,
	get: async ({ context }) => {
	const session = await get({ context })
	const sudoContext = context.sudo()
	if (!session) return
	if (!session.itemId) return
	if (session.listKey !== listKey) return
	try {
	const data = await sudoContext.query[listKey].findOne({
	where: { id: session.itemId },
	query: sessionData,
	})
	if (!data) return
	return { ...session, itemId: session.itemId, listKey, data }
	} catch (e) {
	console.error(e)
	// TODO: the assumption is this could only be from an invalid sessionData configuration
	// it could be something else though, either way, result is a bad session
	return
	}
	},
	}
	}

We also used passport and OAuth to authenticate users using third-party providers, but in the end, we still created a user session in KS.

The flow was like this.

• Frontend clicks link that goes to Backend (KS)
• Backend does the redirect to OAuth using the passport
• On the OAuth provider, the user enters credentials
• OAuth provider redirects back to the Backend
• Backend checks if the user exists based on a unique ID from OAuth
  • If the user does not exist, create it based on a unique ID
• Create a Backend KS session (in a way replicate what is here in KS auth
• Redirect back to Frontend

[dcousens]

@keystone-6/core is ambivalent to your authentication mechanism; the only thing it needs is a Session type.

The answer^ is referring to @keystone-6/auth only, whenyou can easily write your own SessionStrategy and UI to match varying requirements.