what are the rate limits of SSO providers when using the Kinde credentials, for let's say e.g. google? Because I feel like for small apps I could just use Kinde's oauth credentials instead of setting up my own, no?
The documentation advises against using Kinde's credentials for third-party authentication in production environments. While it's possible to use Kinde's credentials for development purposes, this approach is not recommended for live production environments due to rate limiting issues.
Specifically, the documentation states:
"When setting up third party authentication, such as social sign in or enterprise sign in like SAML, ensure you have added the third party Client ID and Client Secret (Keys) to the configuration screens in your live environment. If you don't enter these details, Kinde will fallback to use our own credentials as proxy and this will cause rate limiting. This is okay for local development environments, but not for live production environments."
Unfortunately, the documentation doesn't provide specific rate limit numbers for SSO providers like Google when using Kinde's credentials. However, it's clear that relying on Kinde's credentials for third-party authentication in production is not advised due to potential rate limiting issues.
For small apps, while it might seem convenient to use Kinde's OAuth credentials, it's recommended to set up your own credentials for production use to avoid these rate limiting problems. This ensures better performance and reliability for your users
Hi @dachsteinhustler I can look into updating the docs with this info. However, we don't encourage the use of Kinde credentials - regardless of limits. Is there an issue with setting up the apps in google, etc?
it's just more work to set up the different apps and get them verified and my colleague wanted to skip this step.
But sure, if you all say it's important we'll do it.
Why is it not encouraged though? Because the docs and here people say "it's not advised", but what's the reason actually (I'm not the best with OAuth best practices yet)?
Here's a couple of reasons, let me know if you need more:
If you use our credentials and then decide to move to another auth provider, all your users will be forced to re-authenticate, disrupting their experience.
If we, Kinde, decide to change a config for one of the SSOs, rotate keys, etc. It could break your app.
It is a poor security practice to rely on credentials that are not yours.
@dachsteinhustler it's better when you create the applications you own for multiple reasons:
in case Kinde-provided application stops working for some reason (banned by the provider for example), your users will not be able to authenticate until we fix it on Kinde's side. With your own application, not only the risk of this happening is smaller, you are also in the full control of any visual customizations the provider gives you. One of those, for Google for example, you'll see your application's logo and the domain instead of kinde.com.
another reason, for Apple for example, if you use Kinde-provided application, you wouldn't be able to migrate users from Kinde app to your app, as Apple just doesn't provide this as an option for the subset of users.
Rate limiting doesn't change depending if it's your application or Kinde provided it, the only change is risk that you are decreasing by creating your own apps.
