getAuthenticatorAssuranceLevel() triggers "getSession() could be insecure" warnings

[sleepdotexe]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

Despite not using getSession() anywhere in my code, I am still receiving (numerous) console warnings stating the following:

Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server.

After doing some investigation, this issue seems to only occur when checking the user's MFA status via supabase.auth.mfa.getAuthenticatorAssuranceLevel(). If I remove or replace this call with a static return of 'aal2' values, the warnings disappear in console.

I am using Next.js and server-side rendering with the App router + supabase/ssr.

To Reproduce

1. Follow the guide to set up supabase in a Next.js project as per the docs here.
2. Add a function that performs server-side MFA validation as per the docs here.
   • This function should be run on the server (eg. Server component) and call supabase.auth.mfa.getAuthenticatorAssuranceLevel().
   • In my implementation, the currentLevel property of this call is compared against the defined/expected AAL level for that route, then - if they don't match the expected level` redirects them to the appropriate page (login page, enter MFA code page, dashboard page)
3. Call/await this function in a page or layout.
4. Run the app and then visit a page where this function is called.

Expected behavior

Since I have not called/used getSession() anywhere, I should not be seeing warnings in the console about getSession().

System information

• OS: Windows
• Browser: n/a
• Version of supabase-js: 2.43.1
• Version of @supabase/ssr: 0.3.0
• Version of Node.js: 20.9.0

Additional context

I did some investigation and it seems like getAuthenticatorAssuranceLevel() is referencing the session.user object in this line:

private async _getAuthenticatorAssuranceLevel(): Promise<AuthMFAGetAuthenticatorAssuranceLevelResponse> {
    return this._acquireLock(-1, async () => {
      return await this._useSession(async (result) => {
        // ...

        const verifiedFactors =
          session.user.factors?.filter((factor: Factor) => factor.status === 'verified') ?? []
               // ^----

Some suggestions/thoughts:

• Is getAuthenticatorAssuranceLevel() also meant to be treated as an insecure on the server (like getSession())? If so, this probably needs to be reflected more clearly in the docs to prevent a developer from trying to protect routes based only on MFA status (this is possible since a logged-out user would return null for currentLevel and nextLevel).
• Could the getAuthenticatorAssuranceLevel() be made more secure server-side by calling _getUser? Then the resulting value could be referenced as user.factors instead of session.user.factors. I assume this would add quite a lot of overhead to this function.
• If we don't want to force every implementation of getAuthenticatorAssuranceLevel() to call _getUser by default, could it be an option to pass a user to getAuthenticatorAssuranceLevel() so the developer can define if they want the method to be secure on the server?
• If none of the above is possible, at the very least the warning probably needs to be supressed for this method since it is confusing and irrelevant considering getSession() has not been used anywhere in the code.

I haven't explored too deeply into the source code so hopefully these thoughts make sense.

[kizivat]

There is a PR for that #909

[Collin0810]

Are there any updates on this? We are also using Next.js with the latest SSR package and implementing getAuthenticatorAssuranceLevel() in the middleware to check the users' AAL level. Our logs are flooded with warnings:

"Using the user object as returned from supabase.auth.getSession() or from some supabase.auth.onAuthStateChange() events could be insecure! This value comes directly from the storage medium (usually cookies on the server) and many not be authentic. Use supabase.auth.getUser() instead which authenticates the data by contacting the Supabase Auth server."

Which makes it really hard to debug and read console logs for anything (un)related to Supabase in our app.

[j4w8n]

No updates on this that I'm aware of. There are several places in the code where this happens, besides this method: some examples are updating a user, setting a session, and refreshing a session - if executed on the server side of course. I believe there might be a couple of others.

I'm hoping that after they get some more auth things completed in the next couple of months, that they decide this warning is unneeded and just remove it.

[k-thornton]

omg thank you for posting this. I've been chasing down my particular source of this incessant warning, and eventually traced it to this same getAuthenticatorAssuranceLevel() function.

I suppose unless the maintainers switch this function to use getUser() the correct course of action would be to only use getAuthenticatorAssuranceLevel() on the client side... has anyone gotten this working on their end before I go down that route?

If it's the case that getAuthenticatorAssuranceLevel() Is only intended to be called on the client side, it would be nice for that to be added to the docs, and have a more explicit warning emitted

[k-thornton]

Ok I reimplemented my code to do this check on the client side and the warnings went away. In my case I have a layout file covering an entire Dashboard section of my website, and inside that layout I have a useEffect that checks assurance level and either shows the MFA screen, or the dashboard as appropriate:

export function DashboardWithMFA({ user, userDetails, entitlements, children }: DashboardProps) {
    const [readyToShow, setReadyToShow] = useState(false)
    const [showMFAScreen, setShowMFAScreen] = useState(false)
    const supabase = createClient()

    useEffect(() => {
        ; (async () => {
            try {
                const { data, error } = await supabase.auth.mfa.getAuthenticatorAssuranceLevel()
                if (error) {
                    throw error
                }

                if (data.nextLevel === 'aal2' && data.nextLevel !== data.currentLevel) {
                    setShowMFAScreen(true)
                }
            } finally {
                setReadyToShow(true)
            }
        })()
    }, [])

    return (
        <>
            {readyToShow && showMFAScreen ?
                (
                    <AuthMFA onSuccess={() => setShowMFAScreen(false)} />
                ) : (
                    <DashboardContainer user={user} userDetails={userDetails} entitlements={entitlements}>{children}</DashboardContainer>
                )
            }
        </>
    )
}

Hope this helps someone out there!

[abhishekyelley]

Hey @k-thornton, the warning was to remind us that the token was retrieved from a storage medium (cookies) which could be tampered by the user, right? Which means that there is no secure way of getting the user's aal with the getAuthenticatorAssuranceLevel() function?

[antonsarg]

I hope that the problem will be solved. I can't imagine that moving the query to the client is the best solution when middleware should be the cleanest solution

[abhishekyelley]

@antonsarg I just verify the jwt token with the jwt_secret and then decode the payload like suggested here

[J0]

Hey folks,

Thanks for your patience with us. An update here - A fix is in the works. We'll soon move to an asymmetric model where getSession will be lower risk since we'll only be releasing the public key.

[antonsarg]

@J0 So what is the best way to go for now especially for production?

[k-thornton]

@J0 So what is the best way to go for now especially for production?

https://supabase.com/docs/guides/auth/auth-mfa#server-side-rendering
Based on the docs I'm reasonably convinced the intended method is to do all of the Multi-Factor AAL checking on the client side, in "use client" code. No security warnings that way, and my code more or less matches the docs.

That feels like the way it was intended to be implemented.