understood that the architecture involved my own b...
# support-questions-legacyk
kelchy2714
09/09/2022, 5:56 AMunderstood that the architecture involved my own backend to handle {domain}/auth/* which will proxy to the core. i wonder why ST was designed like this? can my frontend go directly to the core without going through my app backend?
r
rp_st
09/09/2022, 6:24 AMhey!
rp_st
09/09/2022, 6:25 AMThe main reasons are:
- Easier customisability to backend logic for you.
- Allowing us to handle how session management works for your APIs via httpOnly cookies.
k
kelchy2714
09/09/2022, 7:21 AMi have multiple microservices and avoiding to add another one just for authentication. httpOnly is a valid reasoning although it can also be achieved even if core handles it directly through custom domains
r
rp_st
09/09/2022, 7:24 AMWell yea, but then you loose out on a nice dev exp for modifications. Furthermore, for things like session verification, CSRF checks, session updating, enforcing session claims, we would have to build SDKs anyway that the dev has to integrate with their api layer.
rp_st
09/09/2022, 7:25 AMOr else ask the dev to manually enforce those things themselves which can be error prone and annoying (especially for non security experts)
k
kelchy2714
09/09/2022, 7:32 AMi do agree that sdk for the devs is necessary
kelchy2714
09/09/2022, 7:32 AMit makes things easier and more manageable
r
rp_st
09/09/2022, 7:33 AMWe are working on session enhancement as well which will enable to you verify the access token without our SDK (using any JWT lib)
rp_st
09/09/2022, 7:33 AMSo that will help you with your situation
k
kelchy2714
09/09/2022, 7:34 AMi think i did ask that on another thread
r
rp_st
09/09/2022, 7:34 AMYeaa
k
kelchy2714
09/09/2022, 7:34 AMjwt is too clunky, your session is better
r
rp_st
09/09/2022, 7:34 AMWell, our access tokens are a modified version of JWT
rp_st
09/09/2022, 7:34 AMRefresh token is just an opaque token
rp_st
09/09/2022, 7:35 AMWhy do you say that JWT is too clunky?
k
kelchy2714
09/09/2022, 8:07 AMfor one, there's the overhead of requiring additional libraries. then there's this ambiguity around symmetric vs asymmetric approach to it
kelchy2714
09/09/2022, 8:08 AMST creates that wrapper around that which is great
r
rp_st
09/09/2022, 8:08 AMah right. Fair enough
k
kelchy2714
09/09/2022, 8:08 AMbut still, having no read write restrictions to the apikey is a bit of a turn off for me
r
rp_st
09/09/2022, 8:10 AMfair enough. You can open an issue about this on our github, and we can check it out. That being said, session verification would require the ability to write to the SuperTokens core as well - cause sometimes, it requires an update to the access token's payload. So what you really want are API keys scoped to recipes I guess?
rp_st
09/09/2022, 8:12 AMAnd if you really want to, you can implement that using nginx in front of the supertokens core:
- Create multiple API keys for the core
- When a requests hits the nginx server, check the recipe that the request is for, and make sure that that API key is allowed to query that recipe. If it is, let the request pass through, else reject it.
- This way, you can assign recipe level restrictions to API keys and allocate them to various microservices that you have.
k
kelchy2714
09/09/2022, 9:55 AM👍
2 Views