Saaslet manages user signups and logins, account actions like password or address changes and payments - all activities that are closely linked to an authenticated user.
But there's a catch: Whenever a user of your SaaS makes a request to your server, you need to receive that cookie to know who you're dealing with. But that user's cookie was set by saaslet.com - and browsers only sent cookies back to the domain that set them.
To get around this limitation, we ask you to allow us to set cookies for your domain. This can either be done by adding a CNAME entry into your zone file or DNS configuration or by creating a proxy-forward rule for your HTTP server. We realize that this is a bit of extra work - and we're really sorry about that. There would have been simpler solutions, but all of them come with some major security caveats.
Here's what we could have done instead:
Many sites set cookies from multiple sources: Google Analytics, Ad Providers, Tracking Cookies, etc. These are called third party cookies and provide a simple way for multiple providers to keep state. But there are problems: Many people use AdBlockers - and most AdBlockers also block third party cookies. Furthermore, the legal situation for third party cookies in the European Union has made exact compliance a rather convoluted affair
You're probably familiar with the "Sign up with Google/Twitter/Facebook etc." buttons on the web. They work based on an authorization workflow called oAuth 2, which is specifically designed to make authentication via third party providers safe and reliable. But authentication is as far as oAuth 2 goes. It has no concept of sessions, mutable user-data, or payment flows. There are other layers that handle this, built on top of oAuth 2 such as OpenID Connect - but they again rely on your ability to set cookies from your URL.