Kinde•2y ago

custom signin/signup page

Hi im using nextjs and i was wondering where do i pass the password?

<LoginLink
className={styles.button}
authUrlParams={{
connection_id:
process.env.NEXT_PUBLIC_KINDE_CONNECTION_PASSWORD || "",
login_link: email,
}}
>

Login
</LoginLink>

zjOP•5/14/24, 10:29 AM

and another question is what is thebest way to keep the jwt in the browser and keep it getting refreshed until the user logs out. As previously I used the firebase auth and i used to save it as a cookie

Zzj Hi im using nextjs and i was wondering where do i pass the password? <LoginLin...

Oli - Kinde•5/16/24, 12:49 PM

Hey @zj,
You cannot pass in the password via your code/API, only through the hosted Kinde page.

Zzj and another question is what is thebest way to keep the jwt in the browser and k...

Oli - Kinde•5/16/24, 12:51 PM

The best way to manage JWT tokens in the browser while using Kinde is to leverage the built-in token management and refresh mechanisms provided by Kinde's SDKs. Here are the recommended practices:

In-Memory Storage: By default, Kinde's SDKs store JWTs in memory. This approach protects against CSRF and XSS attacks, which are common vulnerabilities when tokens are stored in client-side storage like cookies or local storage.
Automatic Token Refresh: Kinde's SDKs handle the token refresh process automatically. When a token is about to expire, the SDK uses a refresh token to silently obtain a new access token from Kinde. This ensures that the user remains authenticated without needing to manually refresh the token or re-authenticate.
Use of HttpOnly Cookies (Recommended): For a more persistent solution, especially to maintain sessions across page reloads and browser tabs, you can use Kinde's custom domain feature. This allows setting a secure, HttpOnly cookie on your domain that contains only the refresh token. This cookie is not accessible via JavaScript, thus providing protection against XSS attacks and is not susceptible to CSRF attacks.
Avoid Local Storage for Production: While Kinde provides an escape hatch to use local storage (isDangerouslyUseLocalStorageisDangerouslyUseLocalStorage) for storing refresh tokens during local development, it is strongly advised not to use this in production environments due to security risks.

Implementing these practices will ensure that JWTs are handled securely in the browser, minimizing the risk of token theft and unauthorized access.

Let me know if you have any further questions.

OOli - Kinde Hey @zj, You cannot pass in the password via your code/API, only through the hos...

zjOP•5/17/24, 10:54 AM

My issue with this is that i want to login with password not paswordless approach. And i want that i have a custom page to do so instead of being redirected to the kinde default page

zjOP•5/17/24, 10:55 AM

So when i get the password from the user in the input field how do i pass it to the API?

Oli - Kinde•5/18/24, 3:47 AM

Hi @zj,
At the moment you cannot authenticate just via API for email + password. You must use the Kinde hosted page when a user enteres a password. The reason for this is, there is a lot of security risks allowing API authentication and sending a password for auth via API.

zjOP•5/18/24, 5:17 PM

Hi @Oli - Kinde ,

so for me to just use the custom page i must use the paswordless login?

Oli - Kinde•5/24/24, 8:04 AM

Hey @zj,
You can use any authentication method Kinde offers, but you must use the Kinde hosted page for this. So you can use e.g. email + password or email + passwordless (email OTP) login.

The reason we do this is because our hosted login pages safeguard you from a lot of security risks that you otherwise would be exposed to if you hosted your own UI page for authentication (and just used as via e.g. APIs)

custom signin/signup page

Similar Threads

Similar Threads

Similar Threads