Support for proper Bearer/Non-session auth

[dPreininger]

Current implementation and flaws

Medusa currently uses session based authentication for Admin and Store APIs and is starting to user API tokens for Admin users.

Both session authentication ('admin-jwt' and 'store-jwt' passport strategies) and admin API token ('bearer' passport strategy) are flawed and are not following the standards:

Session auth flaws ('admin-jwt', 'store-jwt'):

• Uses express session to handle the session cookie
• Express session saves the session values server side, so the JWT issued by these strategies are stored in the MemoryStore instance server-side. The point of a JWT is to issue it to the client to be stored client-side
• Valid JWT can only be issued by someone who knows the JWT secret, in our case that would be the server. Once it is issued it is cryptograhically signed and cannot be tampered with. That is why the JWT is generally stored by the client, as the client cannot tamper with data written inside the token, such as username, role,... When the server receives the token, it is assumed that all the claims in the token are always correct due to the tamper proof nature of these tokens.
• The real question is: why are we signing and issuing these JWTs if we never send them to the client? There is a line in create-session.ts file: req.session.jwt = jwt.sign({ userId: result.user.id }, jwt_secret, { expiresIn: "24h" }). As session object is stored only on the server, this could be achieved like so: req.session.userId = result.user.id; req.session.expires = { some date }
• PassportJS has built in session auth support, it would be wise to look into that for session auth handling as well, as it supports Redis store and might simplify the codebase, leaving maintainers with less responsibility (following the principle of every line of code is a responsibility).

Bearer auth flaws ('bearer'):

• Currently, the Medusa bearer auth works by giving a user a static API key. This is in fact not bearer auth, but API key auth.
• Bearer auth works by sending the client a JWT token, where you set claims inside that token, such as username, role and/or expiry date. As previously described, these claims are tamper proof, even though the token is sent to client. This means, that session is managed by the client, which is the prefered way for a JAM stack application, such as Medusa.
• This improves CORS issue handling and support for non-web based front-end clients such as mobile applications.
• Allows the client to check if the user is logged in without sending an API request regardless if the back-end is located on the same domain as the front-end, as local storage is always accessible, while cookies are only accessible in the browser, if origin of the cookie is the same as current website.
• Expiry dates can be set. Current strategy with static API tokens does not allow for that.

Proposal

I propose a new implementation, which keeps all current functionalities, but adds a proper bearer auth for both store and admin domains. No breaking changes would be introduced.

• Current session-based auth would be changed to be up to session auth spec.
• Current so called bearer auth using API tokens would be kept, renaming it to user assigned API token auth or something similar. The strategy name can be kept the same for backwards compatibility with some community created plugins or changed, which would introduce a minor breaking change.
• Proper bearer auth would be added using JWT tokens.

I am willing to implement all of this myself. I have worked with one of the core contributors of Medusa, Adrien2p, in the past on his medusa-plugin-auth. I am familiar with the current state of Medusa auth code. I wouldn't need much guidance. The only responsibility core Medusa team would have is to review my PRs.

If my proposal is accepted, I am willing to contribute to Medusa authentication process in the future as well, implementing other features in the backlog, such as SSO support and support for user-defined passport strategies.

Thank you for reviewing this proposal.

[olivermrbl]

Appreciate this proposal and the detailed description of what we could do better regarding authentication @dPreininger!

You are more than welcome to submit these changes in a pull request, and we'll make sure to dedicate time for reviewing. Also, if I can assist in the implementation process, please let me know.

Regarding breaking changes vs. backward compatibility, I'll let you decide. I am willing to accept both approaches. If you find keeping the API backward compatible too messy, I'd rather have us cut a minor bump introducing breaking changes.

[olivermrbl]

If my proposal is accepted, I am willing to contribute to Medusa authentication process in the future as well, implementing other features in the backlog, such as SSO support and support for user-defined passport strategies.

Also, this is great. We'd love your support!

[pevey]

I just want to comment on this bit:

This means, that session is managed by the client, which is the prefered way for a JAM stack application, such as Medusa.

The old Gatsby starter app was JAM stack, and the current official NextJS starter app CAN be used that way if desired, but that is not the only way people are using Medusa. It's important to keep in mind. Medusa's server-side storage of sessions is very important for my implementation.

[dPreininger]

You don't need to worry about that, as the current cookie based session auth, where session is managed by the server will still be available. I will make some changes to it but all of them will internal, so exisiting applications shouldn't break. I am planning to just add another way to authenticate using JWT bearer tokens while slightly improving the existing options.

[dPreininger]

I have opened a PR #4064 that implements these changes.

[dPreininger]

Hello @olivermrbl,

I have opened a PR #4064 quite some time ago that implements the changes outline above. It seems as though the PR has gone unnoticed by the Medusa team. I am kindly asking you to assign someone from the core team to review the PR and provide feedback if something else needs to be changed before the PR is accepted and merged as the Medusa community seems to be excited for the changes proposed.

Thanks,
David

[juanpablocs]

I want to integrate medusa in flutter mobile and I need you to review this proposal please.

[nolawnchairs]

Is there progress on this? I can't think of a single reason that this type of API access authentication is NOT implemented here. Did they seriously not think people may like to use API key authentication? It baffles my mind.

[olivermrbl]

@nolawnchairs, the PR landed on develop many months ago. Please refer to our documentation on authentication.