Replies: 3 comments 2 replies
-
The forum or discord server idea is very interesting, i think it will help grow this package, we should ask @panva what he thinks about this ? As for the cookies, you can customize their path, my personal case is that i had multiple microservices that could handle the upcoming interactions and requests, those microservices are mapped to different paths but on the same hostname, so i wanted to be able to send along the cookies to every path of that hostname (not the choice i know but for now i need it like this) i did it by adding a middleware to the Provider object like so: And then, on the middelware, you can intercept all request before AND after processing by the package, and you can specify what request you want because the requests are categorized like this: In my case i needed to change the cookie path only in 'authorization' route, so when ctx.oidc.route === 'authorization', i can interecpt the request AFTER being proccessed, and do whatever with it, in my case here is what i do: And the function altering the cookie path: in your case, you can just change the domain attribute of the cookie, or just add new cookies for the original domain if needed I'm not an expert of Oauth2 neither but i have learned a lot since these 3 months working on creating a new Oauth2/OIDC identity provider federeated with other IDPs via SAML, the lib is very useful and interesting but it lacks more complete and detailed documentation and best practice conversations, which is understandable because it's an open source library maintaned by one person Thank you @panva for this |
Beta Was this translation helpful? Give feedback.
-
FusionAuth does have an active community forum where you can get help, ask questions, and discuss best practices. The forum is available at https://fusionauth.io/discuss/. Additionally, FusionAuth has an official Discord server where you can join and engage with the community, ask questions, and get support. You can find the Discord server link on the FusionAuth website (https://fusionauth.io/) or directly join using this invite link: https://discord.gg/kWPzjFG8Zp. Regarding using Next.js as the frontend for sign-in and sign-up pages, it is certainly possible. However, you will need to handle the cross-origin resource sharing (CORS) and cookie domain issues. By default, cookies are set for the domain from which the request originates, which can cause issues if your frontend and backend are running on different domains or ports. To work around this issue, you can consider the following approaches:
As for best practices, it's generally recommended to separate the concerns of your application. FusionAuth should handle the authentication and authorization logic, while your Next.js frontend should handle the user interface and integration with FusionAuth. Here are some best practices to consider:
Additionally, FusionAuth provides extensive documentation, guides, and examples to help you get started and follow best practices. It's recommended to review the documentation and explore the provided examples to understand the recommended approach for integrating FusionAuth with your frontend application. |
Beta Was this translation helpful? Give feedback.
-
I use Next.js to render my interactions. I found the This avoids the cross-domain cookie issue you have by serving the Next.js app within the same server, and keeps the Next.js front-end project independent from the oidc provider. import { Next } from 'koa'
import next from 'next'
import path from 'node:path'
import url from 'node:url'
import { KoaContextWithOIDC } from 'oidc-provider'
// Render login interactions using a nextjs project.
// The nextjs project can be changed by pointing the next dir to a different directory.
const dev = process.env.NODE_ENV !== 'production'
const hostname = 'localhost'
const port = process.env.PORT || 3000
const dir = path.resolve(__dirname, '../../wherever-your-next-project-is')
const nextApp = next({ dev, hostname, port, dir })
const handler = nextApp.getRequestHandler()
const prepared = nextApp.prepare().then(() => nextApp)
export const renderNext = async (
ctx: KoaContextWithOIDC,
pathname: string,
locals: Record<string, any>,
) => {
const app = await prepared
ctx.respond = false
ctx.status = 200
await app.render(ctx.req, ctx.res, pathname, locals)
}
export const handleNext = async (ctx: KoaContextWithOIDC, next: Next) => {
if (ctx.request.url.startsWith('/_next')) {
ctx.respond = false
ctx.status = 200
const parsedUrl = url.parse(ctx.req.url!, true)
await handler(ctx.req, ctx.res, parsedUrl)
}
await next()
} Replace these lines from the example interactions (assuming you copied your handlers from the dev interactions) locals.body = views[view](locals);
ctx.body = views.layout(locals); with this // path is full path of the interaction
await renderNext(ctx, `/${path}`, locals) and then mount the export const provider = new Provider('host', { /* config */ })
provider.use(handleNext) You may need to amend Hope this helps with your domain issue. You will have a hard time getting two different domains to share cookies. |
Beta Was this translation helpful? Give feedback.
-
Hey everyone, sorry for being selfish but I'm just curious about the existence of an active forum for this library, like is there an active forum for this library (maybe Discord?) to get help, since I'm new about OAuth 2.0 and OpenID Connect and trying to learn them by building a simple identity provider, OAuth 2.0, and OIDC authorization server, using this package, Nest.js and Prisma (copied the Prisma adapter from this example repo as well).
Also is it possible using Next.js as frontend for signin and signup pages (but then I would get invalid requests, since the cookies are set to that Next.js domain, also how do people implement the frontend using this package)?
What's the best practices and so on...
Details about using Next.js as frontend problem (UPDATE: It's a cookie path issue, since I just realized that domains aren't port specific, and the cookies all have the same domain, but diferent path):
To clarify my problem regarding using Next.js 14 as my frontend signin and signup pages (let's say localhost:4000), what happen is that when a request is made to my backend (where Nest.js and Node OIDC Provider lives, port localhost:3000, tested using https://oidcdebugger.com/) it will redirect the user agent to my frontend (this redirection also sends a set cookie response to the redirected route, which is my Next.js app) and my frontend now has cookies regarding the interaction, but the cookies are set to the domain localhost:4000 (Next.js app), with path /auth/signin which I generate using the following in the oidc config:
And know if I want to get the interaction details at some endpoint (get request to Nest.js app at localhost:3000/auth/interactions/:uid) in my backend that handles the requests like so:
I will get invalid request error since the cookie aren't mounted to the request, because the request is for the domain localhost:3000 not localhost:4000, I have a feeling that creating an endpoint to finish the interaction will also require cookies so still poses a problem for me.
Beta Was this translation helpful? Give feedback.
All reactions