MiddlewareAuthenticationStrategy

[olivermrbl]

We've recently added the concept of strategies to the codebase while building the Tax API. Strategies allow us to override specific tasks in the core project with custom logic. It works by defining a strategy interface, that functions as a contract for what methods (or tasks) are available for you to override within a specific domain.

Let's exemplify this by looking at a current take on a strategy for completing carts.

We've created the following interface that defines a method complete used for completing a cart:

export interface ICartCompletionStrategy {
  complete(
    cartId: string,
    idempotencyKey: IdempotencyKey,
    context: RequestContext
  ): Promise<CartCompletionResponse>
}

In the controller, we've removed all logic and are now simply resolving our CartCompletionStrategy from the dependency container and calling its complete method:

  const completionStrat: ICartCompletionStrategy = req.scope.resolve(
    "cartCompletionStrategy"
  )

  const { response_code, response_body } = await completionStrat.complete(
    id,
    idempotencyKey,
    req.request_context
  )

Finally, we've encapsulated all of the logic from the controller into a DefaultCartCompletion strategy, that is used by default.

This pattern allows you to define your own strategy for completing a cart by creating a class implementing the ICartCompletionStrategy, that takes precedence over the default one at runtime when using the endpoint.

Proposal: AuthenticationStrategy

Implement the strategy pattern for authentication and replace the current flow:

route.use(middlewares.authenticate())

Potential approach:

1. Create IMiddlewareAuthStrategy

export interface IMiddlewareAuthStrategy {
  authenticate(): any // should take some props
}

2. Create DefaultAuthenticationStrategy implementing IMiddlewareAuthStrategy and encapsulate the current flow
   Something along the lines of:

class DefaultMiddlewareAuthStrategy implements IMiddlewareAuthStrategy {
  constructor() {}

  authenticate({ req, res, next }) {
    return (req, res, next) => {
      passport.authenticate(["jwt", "bearer"], { session: false })(req, res, next)
    }
  }
}

3. Remove the current flow and instead resolve the authentication strategy and call its method

Before:

// Authenticated routes
route.use(middlewares.authenticate())

After:

// Authenticated routes
const middlewareAuthStrategy = container.resolve("IMiddlewareAuthStrategy")
route.use(middlewareAuthStrategy.authenticate())

This authentication strategy pattern will allow you to create complete custom authentication logic or use a third party provider like Auth0.

[olivermrbl]

We might consider splitting up step 3 and leverage, that we have an existing middleware service.

So instead of directly resolving the middleware auth strategy we do:

const middlewareService = container.resolve("middlewareService")

route.use(middleService.authenticate())

And then in the middleware service, we add a new method authenticate and use the auth middleware strategy injected in the service:

...
authenticate(props) {
 return this.middlewareAuthStrategy_.authenticate(props)
}
...

[adrien2p]

What you are suggesting sound good to me. I would maybe say something.
We should provide an abstract class to extends that implement the interface. Since we don't know if a consumer is using js or ts. After transpilation an interface does not exists anymore in javascript which will make it less clear to the consumer on what to do. Thats way we are sure to enforce and that we could be able to strongly check if needed

export abstract class BaseAuthStrategy implement IAuthStrategy {
    constructor(protected readonly cradle: unknown, protected readonly configOptions: Record<string, unknown>) {}
    
    public abstract authenticate(...args: unknown[]): Promise<boolean>;
}

consumer would do then in js/ts

export class MyCustomStrategy extends BaseAuthStrategy {
        constructor(cradle: unknown, configOptions: unknown) {
            super(cradle, configOptions);
        }
}

And then in the core we could implement custom strategies if needed.

The abstract class will have the advantage to have some methods already implemented if we need in order to manipulate the strategy behaviour to use it in the core.

[rjhllr]

Love the abstract class idea @adrien2p!

I'm not too sure on calling the strategy from the middlewareService. Changing out the strategy is a pretty easy pattern to follow and provides a single source of truth regarding which strategy (or strategies, see below) is run. This is a contract we agree to with potential devs: replace this strategy and consider load order, you're done. All the while providing a lot of flexibility in how powerful strategies are implemented. This can stretch as far as things like nesting strategies (you can always specify a stack of them as long as you compose them in a single place).

With the proposed second layer of the container-defined strategy being called (or not) by the middlewareService (which can be decorated or wholly overriden by any one plugin) we're taking away the reliability of this contract I think. On the other hand, I really don't see where using the service over a strategy would be beneficial, but maybe I'm missing the point of the middlewareService somewhat. Let me know your thoughts!

[rjhllr]

Everything you wrote in the OP makes a lot of sense to me.

One thing to consider here is that this strategy pattern is something that can fill many gaps that currently set back more advanced feature requests while being easy to implement. I found another example of this while browsing the core regarding display number generation, I'll add another issue for it.

I'll have a go at implementing the MiddlewareAuthenticationStrategy. One thing I'm wondering about is whether this will need changes to medusa-js as well, given that some auth schemes may need to redirect the user.

[rjhllr]

#965

[adrien2p]

While I am working on the platform agnosticism, the authentication strategy should take the http adapter instance as an argument. That instance hold the underlying http framework and will provide de necessary bit and pieces to manage middleware, routes, etc...
The idea is that medusa should never depend on a platform specific dependency and those should be managed by the consumer that choose which platform to use.

In the end, the user would be able to use the abstract strategy class, as I proposed in an early comment, and use the httpAdapter to add the specific platform authentication system, the user depends on.

[adrien2p]

Would it make sense to look at nextAuth which is agnostic and provide everything that could be configured through medusa config?

[revskill10]

I'm blocked at this issue, as there's no way to have custom authentication flow for customer, as we'll want to use another strategy for storefront for customer.

At least, make the authorization bearer auth possible and remove the cookie Auth for customer is one step for further unlocking.

[adrien2p]

Hey there, it is not finished but i started a POC here #1717 it will moves when it will be added to the roadmap 🤘

[greyaxis]

We've recently added the concept of strategies to the codebase while building the Tax API. Strategies allow us to override specific tasks in the core project with custom logic. It works by defining a strategy interface, that functions as a contract for what methods (or tasks) are available for you to override within a specific domain.

Let's exemplify this by looking at a current take on a strategy for completing carts.

We've created the following interface that defines a method complete used for completing a cart:

export interface ICartCompletionStrategy {
  complete(
    cartId: string,
    idempotencyKey: IdempotencyKey,
    context: RequestContext
  ): Promise<CartCompletionResponse>
}

In the controller, we've removed all logic and are now simply resolving our CartCompletionStrategy from the dependency container and calling its complete method:

  const completionStrat: ICartCompletionStrategy = req.scope.resolve(
    "cartCompletionStrategy"
  )

  const { response_code, response_body } = await completionStrat.complete(
    id,
    idempotencyKey,
    req.request_context
  )

Finally, we've encapsulated all of the logic from the controller into a DefaultCartCompletion strategy, that is used by default.

This pattern allows you to define your own strategy for completing a cart by creating a class implementing the ICartCompletionStrategy, that takes precedence over the default one at runtime when using the endpoint.

Proposal: AuthenticationStrategy

Implement the strategy pattern for authentication and replace the current flow:

route.use(middlewares.authenticate())

Potential approach:

1. Create IMiddlewareAuthStrategy

export interface IMiddlewareAuthStrategy {
  authenticate(): any // should take some props
}

2. Create DefaultAuthenticationStrategy implementing IMiddlewareAuthStrategy and encapsulate the current flow
   Something along the lines of:

class DefaultMiddlewareAuthStrategy implements IMiddlewareAuthStrategy {
  constructor() {}

  authenticate({ req, res, next }) {
    return (req, res, next) => {
      passport.authenticate(["jwt", "bearer"], { session: false })(req, res, next)
    }
  }
}

3. Remove the current flow and instead resolve the authentication strategy and call its method

Before:

// Authenticated routes
route.use(middlewares.authenticate())

After:

// Authenticated routes
const middlewareAuthStrategy = container.resolve("IMiddlewareAuthStrategy")
route.use(middlewareAuthStrategy.authenticate())

This authentication strategy pattern will allow you to create complete custom authentication logic or use a third party provider like Auth0.

can you provide the exact path of the files i'm still not able to extend customer authentication

[greyaxis]

i'm using 1.6.0 , what i'm trying to achieve is to extend medusajs/medusa/packages/medusa/src/api/middlewares/authenticate-customer.js this middleware so that i can create custom endpoints and let medusa get authenticated customer from my middleware but i cannot find any docs for this middleware extension

[eparizzi-clevertech]

@adrien2p where can I find the Auth0 work? Is it on some medusa-plugin-auth branch? I need this and I would be willing to contribute.

[adrien2p]

@eparizzi-clevertech hey, it is in progress. I hope it will be ready soon adrien2p/medusa-plugins#27

[matthewpaul]

Hi all - just following up on this thread to see if this authentication strategy addition is planned for release at any point?

[adrien2p]

@matthewpaul there is no plan at the moment, it is already possible to implement custom auth as mentioned in the answer above https://github.com/adrien2p/medusa-plugins/tree/main/packages/medusa-plugin-auth