Features/jwt local auth

[PGLongo]

This pull request is currently a work in progress and serves as an example of implementing JWT. The main goal is to demonstrate the setup and use of JWTs for secure authentication processes.

Here's a brief overview of the changes missing in this PR:

1. Addition of JWT Icon: I haven't find a proper one

2. Dedicated Authentication component: We plan to introduce a new page or modal dedicated to the authentication process. This component will feature a form where users can input their username/email and password.

3. JWT Refresh Logic: totally missing

4. JWT configuration: totally missing

Please note that these changes are still under development, and I'm open to any suggestions or feedback. Further updates and improvements will be made based on the collaborative reviews and discussions.

[PGLongo]

@atinux Would love to hear your thoughts on this!

[atinux]

Hi @PGLongo and sorry for the long answer, I was travelling for conferences.

I am not 100% sure if we should go that way since each auth can have their own logic though.

One solution would be to create itself a /api/login route that make an API call to your endpoint and then save the user session with the token.

Lastly, the user can create a custom fetcher to add the JTW for each API call: https://notes.atinux.com/nuxt-custom-fetch

[PGLongo]

Hi @PGLongo and sorry for the long answer, I was travelling for conferences.

I am not 100% sure if we should go that way since each auth can have their own logic though.

One solution would be to create itself a /api/login route that make an API call to your endpoint and then save the user session with the token.

Lastly, the user can create a custom fetcher to add the JTW for each API call: https://notes.atinux.com/nuxt-custom-fetch

Thanks for your reply.

In a standard JWT authentication setup, we commonly see the implementation of three primary endpoints, each serving a distinct purpose in the authentication process. These endpoints can be personalized in terms of both their URLs and the names of the parameters they use, offering flexibility to tailor the authentication flow to specific application needs. This customization is straightforward, as exemplified by implementations like sidebase-auth.

1. Login Endpoint (/login): This endpoint is responsible for user authentication. It typically requires the user's username or email, along with their password. Upon successful authentication, the server issues a JWT for the user.
2. User Endpoint (/user): This endpoint is designed to handle authenticated requests. It requires the JWT, which is usually passed in the request header. The server verifies this token to confirm the user’s identity and authorize access to protected resources.
3. Refresh Endpoint (/refresh): This endpoint is crucial for maintaining a seamless user experience, especially in long sessions. It takes a refresh token (which is issued along with the JWT) and uses it to issue a new JWT upon the expiry of the current one.

It's important to note that while these endpoints can be customized or the name of the variables, the fundamental principles of secure authentication remain consistent. Customizing these endpoints or variables, as done in sidebase-auth, provides the flexibility to integrate JWT authentication seamlessly into diverse application architectures, while maintaining the core tenets of security and efficiency.

If you would like, I can continue working on this to further evaluate and refine the process. Otherwise, I'll utilize this as a basis for customization. I believe that this functionality, much like basic-auth, can be invaluable for those who cannot rely on OAuth.

[atinux]

I completely understand this but if I want to think a lot on this is because it is not that simple.

Once you have the JWT, how do you call your API? We need to create a custom fetcher for this particular endpoint for example. Talking to an external API is a bit harder than it seems when we need to handle authentication.

We are also exploring right now with the core team how to create a custom fetcher for this particular use case.

[pi0]

Hi dear @PGLongo thanks for putting efforts on this pull request ❤️ I tend to agree with @atinux while also hearing you.

Indeed standard JWT/OAuth flows usually share similar steps of 3 endpoints. But in practice there is lots of differences in order of handling specific parts that needs lots of customizations in behavior for each step according to user's backend and provide setup. Most notably refresh logic that is missing currently.

Having this feature in utils out of the box is so tempting. nuxt auth module, one of the first modules in Nuxt ecosystem, had OAuth implemented for long time but over the time it became totally unmaintainable for us and I'm afraid it will very soon become unmaintable for auth-utils if we do so to cover all specific needs.

As an alternative, i believe we can introduce small composable utility functions that could be used to build a jwt flow rather than providing all of the flow in one event handler to give users to implement a custom fetcher by themselves or used for ready-to-use providers. In parallel to this project, we are working within UnJS ecosystem to provide more of building blocks for making oauth and jwt flows.

[PGLongo]

Once you have the JWT, how do you call your API? We need to create a custom fetcher for this particular endpoint for example. Talking to an external API is a bit harder than it seems when we need to handle authentication.

This module is designed to authenticate users and manage tokens (in this case JWT and refresh tokens). Once it successfully authenticates a user and acquires the token, its job is considered complete.

The responsibility of using this token to make API calls lies with the application itself. The application should create an API client and initialize it with the token obtained from the authentication module. This separation of concerns ensures that the authentication module remains focused on its core functionality - authenticating users and managing tokens - without overstepping into the domain of API interactions.

[ronger-x]

Expect to merge jwt strategies, before this I will try: https://notes.atinux.com/nuxt-custom-fetch