Custom authentification strategy

[olup]

I am aware of the auth plugin and of the recently merged bearer-token authentication feature.

But more generally, how should I go about having a custom code to authenticate a request to the api ?

For instance, I'd like to use a third party auth provider (like clerkjs or even a custom one based on ory) so that my token can be accepted by my ecommerce solution as well as my custom product API that resides on a different server.

How would you go about that ? Is authentication easily customizable ?

Thanks !

[pevey]

This simplest method is to just modify the authService. Replace authenticate function to modify user auth and authenticateCustomer function to modify customer auth. With this method, the initial authentication can be offloaded via those functions, but sessions and tokens and everything else stays exactly the same.

Another approach is to implement auth directly in your app using something like Cognito or clerk or auth0 or whatever. In this case, you will need to change the middleware functions that are attached to the admin and store api routes for authentication. I'm most familiar with Cognito. What I have done experimentally, and what I plan to switch to soon, is use Cognito fully in the storefront app. Handle session in the storefront app. This avoids having to go to the Medusa server on every page load. Calls to Medusa are made only from the storefront app (not the user browser). This is key for this setup to make sense. When the app does need to interact with medusa, it sends the id token from cognito that is stored in user session (which is store in Redis). That id token is verified with Medusa by using the aws-jwt-verifier package on the route middleware.

[olup]

Yes, that's what I am looking for. Can you detail how you have medusa's server only use a custom middleware to authenticate request ?

[olup]

Is that what you were refering to at the start of your message (authenticateCustomer) ?

[pevey]

The service that handles auth requests is here: https://github.com/medusajs/medusa/blob/2b91049f58b2bd70cbee53e1ace7d36f59da6fa4/packages/medusa/src/services/auth.ts

The authenticate method handles user auth. (users in medusa means admin users, aka anything on the /admin routes). The authenticateCustomer method handles customer auth. (meaning, on the /store routes that require auth, which is not all of them)

These methods get invoked via middleware attached to the routes. These are here: https://github.com/medusajs/medusa/blob/2b91049f58b2bd70cbee53e1ace7d36f59da6fa4/packages/medusa/src/api/middlewares/authenticate-customer.ts
And here: https://github.com/medusajs/medusa/blob/2b91049f58b2bd70cbee53e1ace7d36f59da6fa4/packages/medusa/src/api/middlewares/authenticate.ts

[pevey]

I want to clarify, because I misspoke above. It would be more correct to say:

The auth service pointed to handles the INITIAL auth request that is invoked at /admin/auth or /store/auth.

The middlewares do not directly invoke those functions again. They check essentially for the validity of the session or token.

[olup]

Thanks! So overriding the middleware is straightforward to do ?

[pevey]

No, unfortunately. I used patch-package. https://www.npmjs.com/package/patch-package

A change to medusa worth proposing, which would be very easy to implement, is to add two additional functions to the auth service: verifySession and verifyCustomerSession. These could be invoked in the middleware instead of hardcoding the passport verification checks that are in the middleware now. That would make it straightforward to modify the middleware because you could just extend the authService and override those methods.

[olup]

That's what I feared indeed. I am not super keen on patching the package for a production real-money project. Let's see how it evolves.

[pevey]

PR here: #5262

[lukethegeek]

Many thanks for doing this. I'm looking to integrate medusa into an existing website which has authentication taken care of. Having a separate login for a shop section would be unacceptably clunky in terms of UX, but this appears to solve that.

[hienngm]

I've come up with a solution by overriding the passport strategy in Medusa loaders.

export default async (): Promise<void> => {
  passport.use(
    'store-bearer',
    new FirebaseJwtStrategy(
      {
        jwtFromRequest: ExtractFirebaseJwt.fromAuthHeaderAsBearerToken(),
      },
      async (token, done) => {
        try {
          const decodedToken = await auth().verifyIdToken(token);
          const { email, uid: firebaseId } = decodedToken;

          if (!email || !firebaseId) {
            done(null, false);
            return;
          }

          done(null, { customer_id: firebaseId });
        } catch (error) {
          done(null, false);
        }
      },
    ),
  );
  
  passport.use(
    'admin-bearer',
    new FirebaseJwtStrategy(
      {
        jwtFromRequest: ExtractFirebaseJwt.fromAuthHeaderAsBearerToken(),
      },
      async (token, done) => {
        try {
          const decodedToken = await auth().verifyIdToken(token);
          const { email, uid: firebaseId } = decodedToken;

          if (!email || !firebaseId) {
            done(null, false);
            return;
          }

          done(null, { userId: firebaseId });
        } catch (error) {
          done(null, false);
        }
      },
    ),
  );
}