Protections against other services using self-serve API?

[danthegoodman1]

So if I have a deployment of Kratos that has the self-serve interface publicly exposed, what protections exist to prevent someone from using my Ory kratos for Identity management on their platform?

Obviously they wouldn't have access to the admin API or the Oathkeeper integration, but just using the API registration and login flows they could have their own services use my self-serve Kratos endpoints to manage their Identities.

Unless I am missing something?

Edit:
I am mainly referring to the whoami endpoint, since a rogue service could just do a whoami lookup on behalf of the user on my Kratos to get the identity information, and that also tells them session is valid. They could also design interfaces that just talk to my Kratos for login and registration.

I think this probably wouldn't be an issue if the whoami route did not exist, but the fact they can pull that info while also verifying the session is the problem. Honestly this feels like more of a problem with sessions than Kratos because another API that has similar custom endpoints would have the same issues...

[aeneasr]

Similarly you could reverse engineer any mobile app api and probably most SPA apps and make the same observation.

Your question touches on a deeper level. Can I trust the client to be honest, and the answer is always no. That’s not an issue for this software in particular but for any internet application!

To answer your question, there is of course a way for dishonest clients to sign up accounts, as there is for spam bots on wordpress! Adding the appropriate security controls in place (e.g. SameSite Cookies, CORS, Rate Limiting, CAPTCHA) is up to you and your threat model and will prevent (to a certain degree) misuse.

[danthegoodman1]

@aeneasr these are great points. And one thing I’ve thought of in the mean time is you have control over these accounts. If you find that they are made and never use your service, they can be deleted