How are OAuth callback URLs used?

[walshe]

Hi..

in the example app readme.md I seen this:

Review and update options in pages/api/auth/[...nextauth.js] as needed.

When setting up OAUTH, in the developer admin page for each of your OAuth services, you should configure the callback URL to use a callback path of {server}/api/auth/callback/{provider}.

e.g. For Google OAuth you would use: http://localhost:3000/api/auth/callback/google

Isn't an oauth 2 callback url (containing the authorization code, which then gets exchanged for tokens) supposed to be a url to the frontend app rather than a backend api ?

[iaincollins]

Interesting question!

NextAuth.js is able to be a complete solution in a single route because it handles all the types of routes you need under whatever API base path it is deployed under (e.g. /api/auth/*).

This includes:

• Built-in pages (server rendered and use Preact for efficiency)
  e.g./api/auth/signin, /api/auth/signout
• API routes for server-to-server communication
• API routes for OAuth callback URLs
• API routes to return session and other data to the client
  e.g./api/auth/session, /api/auth/csrf, /api/auth/providers

[walshe]

but aren't those all server paths ?

[iaincollins]

What do you mean by "server paths"?

[walshe]

I mean they are paths to the 'backend api'.
I thought oauth callbacks were really supposed to redirect to the frontend/browser where the frontend then takes the authorization code( from the querystring in the redirect) and exchanges it for a token from the identity provider

[iaincollins]

NextAuth.js is full stack solution, in that it is both frontend and backend (Sign in Pages and API), so it handles everything.

It also provides a client API for React, which is basically a fancy wrapper for calling /api/auth/session.

The flow where the client requests a token is the OAuth Implicit Flow. It's an older flow and not one that NextAuth.js uses.

Generally the Implicit Flow usage has been phased out on the web but is still relevant for mobile apps that can't rely on private secrets (e.g. mobile or desktop apps that implement OAuth and have a secret embedded in the source of the app, rather than using a supporting service hosted on the web to handle authentication).

NextAuth.js uses the OAuth Authorization Code Flow and in that flow the tokens are exchanged privately, with the backend of the client sending a secret to the OAuth providers API. It is generally regarded as best practice, compared to implicit flow.

This allows NextAuth.js to avoid exposing Session Tokens or other sensitive data to client side JavaScript, which helps protect against Cross Site Scripting attacks and Session Hijacking.

It also means that NextAuth.js is able to work on clients that don't support JavaScript (though this requires enabling server side rendering for pages, which does come with a performance cost).

[walshe]

yes, I was talking about the 'OAuth Authorization Code Flow'.. in that flow though, isn't the client supposed to be the browser(front end ui) that exchanges the auth code for a token - rather than a server side component doing it?

[iaincollins]

isn't the client supposed to be the browser(front end ui) that exchanges the auth code for a token

Only in a less secure Implicit Flow.

In an Authorization Code Flow the secret remains secret and is not accessible to the browser, and the OAuth service invokes a callback URL that runs server side.

The server side code then usually looks up user profile and passes back data returned from the OAuth provider back to the browser (and persists the data somewhere, creates a session and makes it accessible indirectly via the session).

Some OAuth providers, like Google, actually expect you to always persist the data on initial sign in and don't work as well if used without a datastore to persist users.