Ionic-vue - is custom backend jwt authentication bad idea?

Hi, our backend is in django rest, we started with a web app, now creating the mobile app, using the same backend. For Ionic, is there any disadvantage to using my own user auth implementation? I got all the register/login/logout logic already done in the web app, so I would like to just copy and paste the scripts and create new ionic views, is that ok to do?

Thank you

I don’t see any issue at a high level as long as you followed JWT’s best practices. Whether JWT is the best option is debatable :sweat_smile:

This is a good post with some discussion - Best way to store Bearer token from API?

I would use a secure method for storing your JWT, for example, GitHub - aparajita/capacitor-secure-storage: Secure, flexible storage for Capacitor apps using iOS Keychain and Android Keystore.

Thank you! I read the entire thread … I am using pinia storage to be able to access it easily as we need it for most of the requests, but I don’t think it needs to be super secured, it’s just an interactive recipe + macro tracking app.

My access token lasts 5 hours, refresh 30 days. I store refresh in pinia preserve but it feels unsecure to just store it like that so I was thinking about some encryption, but again, the nature of the app is far from banking or investments, so I really want to give it just the time absolutely necessary :smiley: the macro tracking part is worse I need more time for that :smiley:

So you would recommend capacitor-secure-storage? Or do you think in my case it wouldn’t be even necessary?

Thank you, you save my life, I am doing a mobile app for the first time ever, rly worried about messing it up.

I am still using @capacitor/preferences but would switch to secure storage if I did it again or have time to switch to it :slight_smile:

Pinia by default is just stored in memory. Are you syncing Pinia to a long-term storage?

1 Like

I am not sure I understand the question. :sweat_smile: Do you mean persisted pinia? Yes I use that for refresh tokens, all the rest is just session memory in a store, but refresh token stays in localstorage through pinia persisted state

 persist: {
        storage: persistedState.cookiesWithOptions({
            maxAge: 60 * 60 * 24 * 365,
        }),
        paths: ["refreshToken"],
    },

Got it. Any storage in the browser/webview like local storage is not guaranteed to be kept that is why I use @capacitor/preferences to store the API key. If you are going to implement that, you might as well implement secure storage :grin:

1 Like

awesome thank you! Marking as solution but when I am at it I am sorry in advance, pretty sure I will bother you again :smiley: thank you!

1 Like

It can be done , Most of the times its not worth it, however ever wondered why like the majority of companies use a solution for authentication , its 2 things maintenance , and for legal reasons basically when the auth does not do its job your not blamed for anything neither you or your company , just the service used for authentication , take crowd strike for example , everyone is blaming crowd strike, not how they could have used another tool that does not access the windows kernel for security measurements.

Thank you! What would be the times not worth it according to you? Interested to know. With me I am tempted to just use the structure I already have that was done like a year ago and is well maintained. The backend has all the things in house taken care of, password reset, email verification, we use sendgrid automation for that, password encryption, I don’t want to implement a new structure for the mobile app if not absolutely necessary, so far I am more inclined to just use capacitor secure storage to store the token on the device but keep the login logic as we already have it.

1 Like

When youre well maintaing the project there is no issue, and you dont have to implement a new structure , if it has worked well for you , most times i mean when there is just a small team working on a project , using a service like auth0 for example is so much easier , and more secure since that you have a larger team updating and maintaing that auth mechanism , it just depends on how you would implement it , from your context however if your team has capacity to maintain the project then using a service like that is not necessary at all , however if there is room for more security why not ? you dont have to restructure , however if you can adapt your implementation with capacitor secure storage which has encryption support , it makes it harder for a hacker for example to decrypt tokens , cookies and request when most of your project is on a backend and utilizing an encrypted local storage system , there is always room for improvement , you can try on a development server if youd like .