4 ms·
This is an idea that I briefly pursued for the same reasons you list, namely that it's a ubiquitous problem which needs to be solved repeatedly. But in a rough
by tacitusarc 6y ago
This is an idea that I briefly pursued for the same reasons you list, namely that it's a ubiquitous problem which needs to be solved repeatedly.
But in a rough design sketch as to how I would create a generic solution, I made the auth service a proxy for the main app. So user data would be verified and decoded in the proxy, and the app could trust the passed token. This removes the need for a back end driver.
I'm curious about why you didn't choose this approach, and instead made the auth service callable from the app?
- rishabhpoddar 6y agoThis is a complicated decision to have made and perhaps a blog post is needed for this. But here is an attempt to answer it: A complex enough app will require modifications to the auth flow. Most services achieve that via webhooks or by forcing devs to write code in their "dashboard". This code would then live outside the main codebase which is annoying. So we thought that if someone was making their own auth, they would want to have all their code in their backend API itself. The best way to allow that was to hide the auth server behind their API server (which is a proxy to the auth server for certain APIs like sign up / sign in etc..)
- tacitusarc 6y agoI suppose another upside is that you can do token validation in the app and not need to have proxy communication on every request.