Add features for refresh token

[guilherme-codes]

I'm having trouble handling refresh tokens because setUserSession doesn't update the session. So, I'm considering the possibility of adding options to setUserSession or returning an updateSession function along with the useUserSession composable.

Other ideas could be add options to refresh token in the route files... and maybe add the refresh token method to the providers definitions too.
I'd like to know people here think about this

P.S: I read the others topics talking about this issue and I think we don't have a good solution yet

// expose update session
const { updateSession } = useUserSession()

updateSession( {
  token: 'token',
   refresh_toke: 'token'
})

// allow session mutation by setUserSession
setUserSession(event, {
  token: 'token',
   refresh_toke: 'token'
}, { updateSession: true })

// add refreshtoken callback
export default defineOAuthAuth0EventHandler({
    async onSuccess(event, data) {},
    async onRefreshToken() {}
})

[Crease29]

Hey, I'm having a similar issue when refreshing the auth0 access token. I'm calling setUserSession with the new tokens. They get sent to the client correctly, but it seems like on the next refresh request the server still has the old tokens in the UserSession. Have you found a fix/workaround for this already?

This is my workaround for now: #357 (comment)

[guilherme-codes]

@Crease29 I did my own implementation for now. It is based on nuxt-auth-utils and shows how I think we should have control of sessions sending requests directly to a Nitro server using composables.

https://github.com/guilherme-codes/nuxt-auth0

[nerdoza]

A fix is potentially on the way for this in h3js/h3#1004, but in the mean time here is a simple HACKY fix to reset the createdAt on the session object to cause the cookie expiration to move forward.

// Grab a copy of the session data object
const session = await getUserSession(event)

// update the `createdAt` time on the session object
Object.entries(event.context.sessions ?? {})
  .forEach(([ k, v ]) => event.context.sessions![k] = { ...v, createdAt: Date.now() })

// Call update to ensure the cookie gets sealed using the updated date
await setUserSession(event, session)

A full implementation for a refresh endpoint would look something like this:

// server/api/_auth/refresh.get.ts
export default defineEventHandler(async event => {
  const session = await getUserSession(event)
  if (session && session.user) {
    /**
     * @todo: remove hack once session fix is released
     * ref: https://github.com/unjs/h3/pull/1010
     */
    Object.entries(event.context.sessions ?? {})
      .forEach(([ k, v ]) => event.context.sessions![k] = { ...v, createdAt: Date.now() })
    await setUserSession(event, session)
    setResponseStatus(event, 204)
  } else {
    await clearUserSession(event)
    setResponseStatus(event, 401)
  }
})

[rsoltanzadeh]

The above hack is the only thing that works. I am confused regarding how people find it possible to use session management without refresh capabilities. Maybe I am missing something. Doesn't this bug mean that users randomly get logged out once the session expires, with no option of refreshing it (other than this workaround)? Wouldn't that make this library basically unusable? I'm sure I'm missing something here since that's clearly not the case.

[nerdoza]

@rsoltanzadeh, I tend to agree with you, but I wouldn't go so far as to say it's unusable. The issue is ultimately with how h3 handles sessions, not this library specifically. I wasn't able to get any traction on getting my PRs merged for h3 fix, so I've been using this hack in production for several months now and it's stable and works fine.