Ask HN: OAuth or Session Management? Authentication between SPAs and back end
10 comments
IMO you should keep secure cookies with a JWT in it, ideally w/ public key crypto. No need for oauth if you're building 1st party.
For context, we're building Saasform as a "secure infra" for SaaS with auth+payments. The idea is to deploy a microservice to handle auth but consider it a 1st party (wrt solutions like Auth0 that would act more like a 3p).
Here I have a guide that goes through some details. You may want to check the notes about SAPs. https://docs.saasform.dev/start/integrate-user-authenticatio...
For context, we're building Saasform as a "secure infra" for SaaS with auth+payments. The idea is to deploy a microservice to handle auth but consider it a 1st party (wrt solutions like Auth0 that would act more like a 3p).
Here I have a guide that goes through some details. You may want to check the notes about SAPs. https://docs.saasform.dev/start/integrate-user-authenticatio...
Thank you very much. The guide is very helpful!
If you deploy the auth handling as a microservice, how do you sync state between the auth-service and the ressource-service. (For example if the token is revoked). Do you use web hooks?
In that case, what addional implementation would I need to add If I want to assure consistency/ implement transactions? Do you have any axperience in that field.
Edit: I just realized that revoking could be done simply by changing the signing key, but that would revoke all JWTs...
If you deploy the auth handling as a microservice, how do you sync state between the auth-service and the ressource-service. (For example if the token is revoked). Do you use web hooks?
In that case, what addional implementation would I need to add If I want to assure consistency/ implement transactions? Do you have any axperience in that field.
Edit: I just realized that revoking could be done simply by changing the signing key, but that would revoke all JWTs...
This is where my opinion may slightly differ from the blog posts you cited. Keep in mind that my experience is more consumer-like vs e.g. a financial institution, so requirements may be different based on your application.
The main question is: assuming you detect a weird case, are you going to conservatively log out the user or risk that an attacker might be taking over the account? I'm for the latter, of course under the assumption that auth is not your last line of defense, but you'll monitor the user/attacker activity and block the account if you think it's an attack. If I were to build a financial app, I'd definitely opt for the former.
My other assumption/experience is that storage is cheap, so you should store (a reference to) all valid tokens. Revoke is then done by marking the record as revoked and/or delete the record.
Now, when the resource service receives an authenticated call, you can either:
1. Check the token against the "list of all tokens" storage (likely exposed by the auth service). Or,
2. Trust that the token hasn't been revoked before expiration.
One way you can achieve 2) is for example to have your frontend to periodically pull the auth service and either receive a refreshed token, or get the cookie cleared out.
The main question is: assuming you detect a weird case, are you going to conservatively log out the user or risk that an attacker might be taking over the account? I'm for the latter, of course under the assumption that auth is not your last line of defense, but you'll monitor the user/attacker activity and block the account if you think it's an attack. If I were to build a financial app, I'd definitely opt for the former.
My other assumption/experience is that storage is cheap, so you should store (a reference to) all valid tokens. Revoke is then done by marking the record as revoked and/or delete the record.
Now, when the resource service receives an authenticated call, you can either:
1. Check the token against the "list of all tokens" storage (likely exposed by the auth service). Or,
2. Trust that the token hasn't been revoked before expiration.
One way you can achieve 2) is for example to have your frontend to periodically pull the auth service and either receive a refreshed token, or get the cookie cleared out.
Hey,
We're the authors of the dzone article amongst others that you can find on our blog (supertokens.io/blog) on similar topics.
The reason Okta, Auth0 use OAuth 2.0 is because they are considered 3rd parties to your own backend. The user logins to Okta / Auth0 as the IdP and then they provide your app access to their backend to access the user's information.
With SuperTokens, the user is signing into your own backend as opposed to a 3rd party and hence OAuth is not required. Hope this answers your question!
We're the authors of the dzone article amongst others that you can find on our blog (supertokens.io/blog) on similar topics.
The reason Okta, Auth0 use OAuth 2.0 is because they are considered 3rd parties to your own backend. The user logins to Okta / Auth0 as the IdP and then they provide your app access to their backend to access the user's information.
With SuperTokens, the user is signing into your own backend as opposed to a 3rd party and hence OAuth is not required. Hope this answers your question!
Thank you, that was exactly the point that I was missing!
I was only looking at the communication between front end back end which i both own. Thanks to you, I now understand my wrong way of thinking.
Would you consider this way of explaining it as correct: If I look at it from another perspective it is pretty much like the normal oauth use case. By trusting Auth0/Okta I share my users and the backend access with them. Since the frontend is 3rd party to Auth0, it is like the normal use case: They provide a application(my frontend) the permission to get access to "their" users data and to commit actions on behalfe of "their" users.
To be honest: Secretly I was hoping for you to answer, as I know that you are activ on HN ;). Your articles are under the best ressources I found on this topic. I espescially like your 2part series on session management!Thanks for your work for the community! I also looked into SuperTokens and find it very promising as I believe that it is extremly important to adress the problem of token theft. In the future that will be crucial as other attacks get less promising due to more secure websites.
I am still a student and I am currently working on my thesis. My target is to create a full-stack data management plattform for the company I writing my thesis at. (I do this completly on my own.) The plattform will be accessed over a SPA. As you can probably imagine that is a not a easy task without having done something of this size before. I want to do it right from the ground of. I want the plattform to be scalable, maintainable and secure. I already read tons of articles, books etc. But I am still looking to improve my knowledge to make no mistakes that i realize while Implementing the plattform.
On the same time, I have to look into ways to outsource work where it is possible. Otherwise I don't think I am able to deliver in time. My application requires User management, and role dependend authorization as well. How big do you consider the overhead of using Supertokens and implementing the user management on my own, to just using Auth0/Okta? I really love the additional security that SuperTokens provides. But If I am unable to deliver in time, thats pretty much worth nothing.
Excuse my many questions please. You have my understanding if you do not have the time to deliver this kind of support on HN.
I was only looking at the communication between front end back end which i both own. Thanks to you, I now understand my wrong way of thinking.
Would you consider this way of explaining it as correct: If I look at it from another perspective it is pretty much like the normal oauth use case. By trusting Auth0/Okta I share my users and the backend access with them. Since the frontend is 3rd party to Auth0, it is like the normal use case: They provide a application(my frontend) the permission to get access to "their" users data and to commit actions on behalfe of "their" users.
To be honest: Secretly I was hoping for you to answer, as I know that you are activ on HN ;). Your articles are under the best ressources I found on this topic. I espescially like your 2part series on session management!Thanks for your work for the community! I also looked into SuperTokens and find it very promising as I believe that it is extremly important to adress the problem of token theft. In the future that will be crucial as other attacks get less promising due to more secure websites.
I am still a student and I am currently working on my thesis. My target is to create a full-stack data management plattform for the company I writing my thesis at. (I do this completly on my own.) The plattform will be accessed over a SPA. As you can probably imagine that is a not a easy task without having done something of this size before. I want to do it right from the ground of. I want the plattform to be scalable, maintainable and secure. I already read tons of articles, books etc. But I am still looking to improve my knowledge to make no mistakes that i realize while Implementing the plattform.
On the same time, I have to look into ways to outsource work where it is possible. Otherwise I don't think I am able to deliver in time. My application requires User management, and role dependend authorization as well. How big do you consider the overhead of using Supertokens and implementing the user management on my own, to just using Auth0/Okta? I really love the additional security that SuperTokens provides. But If I am unable to deliver in time, thats pretty much worth nothing.
Excuse my many questions please. You have my understanding if you do not have the time to deliver this kind of support on HN.
> "Would you consider this way of explaining it as correct.."
Yes, that is correct. Ideally, for the most secure setup, you should use the authorization code grant flow - which would involve your backend gaining access to Okta / Auth0 rather than your frontend. But yes, many people use the default setup which involves their own frontend having access to the user's info on the IdP. The default setup may also involve using localstorage with Auth0 (which we do not recommend - as do many other bodies such as OWASP and NIST).
Glad you liked our articles!
> In terms of implementing user management:
We provide the ability the following user management functions: - Loop through all users - Ban / unban via session revocation - Adding / modifying user roles to session and fetching them in a backend API (post session verification) and frontend
What we don't have: - A UI to manually see / edit the info mentioned above - Delete user functionality (we plan to add this)
So if you can do without the things we don't have, then it shouldn't take much time for you.
Feel free to join our Discord at supertokens.io/discord if you like!
Yes, that is correct. Ideally, for the most secure setup, you should use the authorization code grant flow - which would involve your backend gaining access to Okta / Auth0 rather than your frontend. But yes, many people use the default setup which involves their own frontend having access to the user's info on the IdP. The default setup may also involve using localstorage with Auth0 (which we do not recommend - as do many other bodies such as OWASP and NIST).
Glad you liked our articles!
> In terms of implementing user management:
We provide the ability the following user management functions: - Loop through all users - Ban / unban via session revocation - Adding / modifying user roles to session and fetching them in a backend API (post session verification) and frontend
What we don't have: - A UI to manually see / edit the info mentioned above - Delete user functionality (we plan to add this)
So if you can do without the things we don't have, then it shouldn't take much time for you.
Feel free to join our Discord at supertokens.io/discord if you like!
Thank you for your time, your answers really helped me out!
frontend <-> backend, use JWT
users <-> frontend, use OAuth
users <-> frontend, use OAuth
Can you explain that further. You mean OAuth for signing in users at the frontend?
If your goal is a login, I would say yes. You will have fewer headaches using another IDP like google or something to deal with user auth.
Some articles like [1], [2] seam to share the opinion that OAuth should be used in its traditional use case: "Granting an applications the access to the resources of a user/resource owner or the do actions on behalf of the resource owner"
[1] https://dzone.com/articles/oauth-20-vs-session-management
[2]https://www.ory.sh/hydra/docs/concepts/before-oauth2
On the same time I know that SaaS like Okta, Auth0 etc. are often used to solve the problems of authentication or session managment. But those Services do use OAuth2.0.
On the same time there are Solutions like supertokens or Ory Kratos, that do not use OAuth2.0.
Honestly: I am very confused what solution is the best regarding security and ease of deployment.