Overriding API Admin Authentication in V2

[AlexAntonides]

Hi all,

I'm currently working on a project that requires me to replace the default admin API authentication in order to authenticate with my own authentication server.

While I've successfully created a custom authorize() middleware and applied it to my own routes, I'm also looking to extend its use to the existing admin routes (such as /admin/products and /admin/orders).

However, I've noticed that my middleware isn't functioning as expected for these admin routes, as they seem to be utilizing the default authentication mechanism. I've explored the authentication opt-out using export const AUTHENTICATE = false, but this is only applicable to custom routes and not the built-in ones.

Is there a way to achieve this without overriding the 'framework' module? Or is this perhaps an oversight that will be addressed in the future?

[Deroswent]

Signed up for updates on this topic.

I find Medusa v2's built-in authentication to be just awful and very non-functional + completely non-flexible.

I've been trying to do something similar and implement my own way of authenticating both administrative routes and client routes using next-auth. After studying a bit the authentication module of Medusa v2, I concluded that it would be extremely difficult to achieve this because the built-in authorization module is not something standalone. It is very tightly integrated with the core, such as api keys and sales channels. So, even if you make your own authentication module, a lot of features that the core provides will no longer work properly. And it will not be possible to fix it adequately without interference in the core of the system. Perhaps I lacked knowledge, but my current conclusions are as follows.

Hopefully in the future, the development team will separate the authentication module from the core or add the ability to use their own authentication providers.

[AlexAntonides]

@Deroswent, I've managed to find a hacky solution for the issue I'm facing. I've created a custom middleware that intercepts Medusa's 401 status and lets it pass on to the next middleware in the chain, allowing me to attach my own authorization middleware.

I'm not sure if this would solve the issue for you as well, but it's something I can recommend as a temporary solution. I'm just hoping that the Medusa team will separate the authentication from the core logic in the future.

[AlexAntonides]

I noticed in a recent merged PR the introduction of a non-overridable middleware (again), but this time for store endpoints (ref) with the introduction of required publishable keys. While I understand the need for this, it might limit the extensibility of the authentication, similarly to the issue described above, when running Medusa as a standalone backend service.

Would it be possible to make these middlewares (both the admin authentication as described above, and now the new publishable keys) overridable instead?

[AlexAntonides]

Now with v2.0.9-preview, requiring publishable API keys for /store endpoints, I hope that in the near future the standard medusa API middlewares are overridable or disableable (both bearer and API key), otherwise it wouldn't be possible for us to use Medusa v2.

[olivermrbl]

@AlexAntonides, can you share more about why the publishable keys requirement is hindering you from using 2.0?

[AlexAntonides]

@olivermrbl, thank you for your response,

To give you more context, we’re using Medusa as a standalone backend service with our own authentication/identity server. This identity service takes care of our users, customers, tokens, and API keys, therefore we have no need for the default Medusa authentication.
We want to be able to send the bearer token generated by this identity service to our Medusa instance, and let our Medusa application validate the given bearer token/API key through a middleware on all routes. Additionally, we would like to retrieve the users/customers from our identity service.

In Medusa v1, we were able to solve this by overriding the ‘passport’ loader and use the passport package to override the “admin-bearer” strategy.
In this strategy, we used a jwksClient to retrieve the signing key from our authentication service, and verify the bearer token by specifying the algorithm and issuer.
Additionally, we removed the foreign key constraints from the database tables requiring user/customer IDs so that we were able to insert our own user/customer IDs into these tables.

With the announcement of Medusa v2, we were excited that the Authentication and API Keys Module would allow us to override all authentication in a separate module.
However, so far, the standard Medusa v2 API authentication is mandatory and unoverridable, unlike v1. We even checked the opt-out option export const AUTHENTICATE = false, however, this opt-out is only for custom routes, and not all Medusa routes.

So far, we’ve been trying to scour the code base trying to find a solution. We’ve looked at possible hacks, like creating a Medusa user for every user in our identity service, but this is an overkill, considering we’d be storing the data twice. We also thought about creating a single “admin” user with an API key that can be used for the initial authentication, but this isn’t a good solution for our development environment, and then we can’t identify individual users anymore for each request.

Now, with the introduction of the publishable key requirement, it seems like there is another default and mandatory Medusa authentication that we can’t circumvent.

We were hoping that the API route authentication was solved on the Authentication module, so that we were able to override this module, rather than on the framework making it mandatory and unoverridable. However, it doesn’t seem like this is a plan for Medusa v2, so we’re now only hoping to be able to opt-out on all Medusa authentication, rather than only the custom routes, so that we are able to create our own API route authentication middlewares for all of our routes.

[petrpatek]

Yeah, I am basically doing the same and I am stuck for like 2 days now... It would be really helpful to have this possibility. It is not possible to use Medusa JS with SSO for our corporate customers.

[SalahAdDin]

How is it going on?

[ColeIsaacHarris]

I would really appreciate it if someone from the Medusa core team could comment on this issue. I'm in the planning stages for an application that requires the use of a dedicated IdP, and the limitations outlined in this discussion are unfortunately looking to be a deal breaker when it comes to choosing Medusa for our app, which is really a shame as I otherwise love the look of the framework.

Is the core team open to addressing this issue, or should I look elsewhere for a framework with more flexibility in this regard? I understand you likely have other more pressing concerns to address within this project, but I would urge you to consider the importance of insuring that Medusa remains the no-brainer alternative for people looking to escape the restrictive, inflexible solutions offered by the current leaders in this space.

Thanks!

[dstawinski]

I am also looking at that issue in our case. We would like to login admin users using different identity provider than medusa and it totally blocked at this point.

[AlexAntonides]

@dstawinski
We managed to 'hack' our way into overriding their authentication middleware by loading our own express app and override any of their 401 responses.

        app.use("/admin*", ourOwnAuthorizeMiddleware())
        app.use(
            "/admin*",
            async (
                req: MedusaRequest,
                res: MedusaResponse,
                next: MedusaNextFunction
            ) => {
                const _status = res.status.bind(res)
                res.status = (status: number) => {
                    if (status === 401) {
                        return {
                            json: (message: string): void => {
                                return req.next()
                            },
                        }
                    } else {
                        return _status(status)
                    }
                }
                return next()
            }
        )

It's not the cleanest solution, but it works.

[petrpatek]

How do you create the Medusa JS admin session then? I am completely lost in the integration of custom auth to Medusa JS v2. I would be super grateful if you would point me in the right direction, please.

[AlexAntonides]

@petrpatek, I'm afraid I can't be too much of a help with that, considering we strip away the authentication to replace it with our bearer token.
You could try to look through the codebase to see how they create a session, or perhaps forge your own session?

[petrpatek]

Thanks for pointing me in the right direction. It worked!

[SalahAdDin]

Thanks for pointing me in the right direction. It worked!

were you able to extend admin authentication?

[petrpatek]

Yeah, I basically overrode the middleware and forged my own session. I guess every use case is different, but the middleware shared by @AlexAntonides is the base building block.

[nicolaracco]

I’ve taken a slightly different approach and detailed it in this post: https://medium.com/@nicola.racco/implementing-sso-for-medusajs-admin-dashboard-98e80b797781

I’d really appreciate your feedback, especially if you spot any issues in the code snippets. I had to strip out some project-specific details, so it’s possible a few errors slipped in. Let me know what you think!

[SalahAdDin]

I’ve taken a slightly different approach and detailed it in this post: https://medium.com/@nicola.racco/implementing-sso-for-medusajs-admin-dashboard-98e80b797781

I’d really appreciate your feedback, especially if you spot any issues in the code snippets. I had to strip out some project-specific details, so it’s possible a few errors slipped in. Let me know what you think!

do you have any repo?

[nicolaracco]

I've updated the post to link it.
You can find the repo here: https://github.com/condensetech/medusajs-sso-admin-example

[SalahAdDin]

I've updated the post to link it. You can find the repo here: https://github.com/condensetech/medusajs-sso-admin-example

nice. thank you!