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.