How to verify that a user is currently authenticated on a separate non-JS API endpoint?

[mariomeissner]

I have a NextJS app router project with Auth.js v5 using the database session strategy. I also have a separate Python REST API endpoint. I want to verify that the requests to that API are coming from authenticated users only. The requests would come from a client component. I understand that I should pass some sort of token to the API call and then check whether the user has an active session in the database. However, I don't know which token to pass and how to obtain it. Could I get some guidance on that?

[mariomeissner]

I did find https://authjs.dev/guides/integrating-third-party-backends but two things confuse me:

• The JWT token is not available when using database session strategy, right?
• It's not recommended to expose this token to the client, so it shouldn't be added to SessionProvider for use in client components, right?

Nonetheless, the client code does have some sort of token for Auth.js to verify whether client code is authenticated, so there must be a way to use that instead. I read in https://authjs.dev/concepts/session-strategies that there is a cookie value for this. Should I read that cookie and add it to the request to my other API endpoint?

[mariomeissner]

It seems there is a cookie authjs.session-token with a value that matches the database session token, so I guess we should be using that. However, it's an HttpOnly cookie so I can't access it in my React client component. Would that cookie still be attached to the request I make to my other endpoint? If so, I just need to read the cookie there, so no changes are needed on the JS side.

[mariomeissner]

I've done the following:

• Added credentials: include to my fetch request to my API endpoint, and verified that the cookie is sent
• Read the cookie on my endpoint and fetched the session from my database
• Verified that the session is not expired, and that there is a valid user associated to it

I'm wondering if there are any security flaws to this approach, it sounds reasonably solid to me.

[micolous]

I'm having a look into this for a similar environment, where a NextJS app (built by someone else) would communicate with a non-JS backend (resource server) protected with OAuth, and ideally the NextJS app itself has no server-side components (ie: serve the app from a simple storage bucket).

The security risk that I think the documentation is trying to address is if you make an authorisation decision on the client side.

For example, an app might have paid "gold accounts" which gave access to premium content. A page that made an authorisation decision on the client side would look something like¹:

"use client"

export default function Page() {
  // Get an OAuth 2.0 token (encoded as a RFC 9068 JWT) which was copied to a cookie.
  const token = getToken()

  // Does the user have a gold account? If not, upsell!
  if (!token?.user.is_gold_account) {
    return ( <p>Buy a gold account today! Only $100 per month!</p> )
  }

  // User has a gold account, give them premium content.
  return ( <p>Here is some premium content for you: ... </p> )
}

Because the authorisation decision is made within a client-side component, a user can always inspect the client-side JavaScript or use a debugger to patch out that if statement at the start to access the premium content.

But if the client-side component instead made a fetch() call to a backend (resource server) with the user's access token, then the backend would be responsible for making the authorisation decision, so there's no security risk associated with that approach.

Something to be mindful of when building an SPA from client-side components is that all of its functionality is visible to all users. A couple of issues that come from that are:

• Size: sending large amounts of client-side components will add to page load times; though NextJS has tools to address that.
• Scope: if your app has an interface intended for administrators only, all users will be able to see how that works (eg: UI, strings, API calls), and you need to make sure that your backend explicitly checks for authorisation to use admin APIs, and not just trust the presence of a token implicitly.

It'd be nice if it could avoid having a server-side JS component at all, because then whatever is hosting the server-side JS doesn't need to process authorisation codes at all, and the client-side JS can just be a public client. My read of the third-party backend integration doc is it assumes that you'll always have some server-side JS component to proxy requests to the backend.

Footnotes

1. I don't expect this to be valid TypeScript/Next.JS use, treat this as pseudo-code. 😄 ↩