Best way to authenticate and authorize a SPA/PWA?

Best way to authenticate and authorize a SPA/PWA?
0

#1

I want to create a PWA with its own authentication system. I’ve read about JWT and personally I don’t trust them. Also read about OAuth2 which seems to be solid (and hard) enough, but it was mainly designed for granting API access to third party clients. That’s not really what I need, I just need to create a web app that runs on my own (sub)domain(s) and also an installable PWA/SPA, both consuming from api.myapp.com. I believe OAuth2 may be overkill in this case. Or not? Let me explain myself:
Since populating a client_secret to front-ends is not recommended, If I decide to implement OAuth2 I should use Implicit grant type for my app (which is the less secure approach), right? I’m confused about it because in some articles I’ve seen people using Client Credentials grant on javascript apps, exposing the client_secret to “log in” users, I’ve also read developers write about a password grant type, isn’t it the same as implicit grant type?
Lastly, talking about authorization, let’s say I have a blog in my app, and each users’ access_token has create-posts scope as a permission. What if I now develope a forum and want to grant the reply-posts scope? Should I manually revoke all accessTokens and ask them to log in once again, so they requests this reply-posts scope?
Lots of questions :frowning:


#2

Why not? OAuth has more moving parts, but it uses JWTs under the hood.


#3

Just use PassportJS and don’t sweat the details. You can find tons of tutorials on setting up Passport for various strategies, including local authentication. Here’s one that covers several at once. If you’re some sort of masochist who feels the need to handle the nitty-gritty yourself, authentication is just a pattern of receiving user credentials, comparing the password to a hashed version in your database, and returning a login code if it matches. There’s no magic, but it’s a lot of tedious work, and if you want to allow logins via GitHub, Google, or whatever, scaling that approach can turn tedium to a nightmare.

Also, JWTs are great. Embrace the JWT.


#4

No reason to not trust them. Jwt is widely adopted and is actually safer than session based authentication.


#5

Really interesting answers! I think I’ll throw you some heavy linking just for the sake of understanding each other in a better way.

No reason to not trust them. Jwt is widely adopted and is actually safer than session based authentication.

Since I’m a newbie at authentication with own APIs, at the moment of reading this article Stop using JWT for sessions (and its part 2)

The real problem here I think is how I want to protect the API (allow-origin headers) and ACL with JWT… I don’t know, it’s too hard for me at the moment T_T


#6

I won’t claim to know better than the author, and I can tell there are some good points, but I think he’s missing the point of JWTs. A lot of his points come down to, “JWTs just do what sessions do anyways, but sessions are more secure by way of maturity”. That seems silly to me since they’re supposed to be a replacement for sessions in an age where JSON is the de-facto standard for encoding data. Other arguments are outright wrong, such as when he says that JWTs are much larger than session cookies or that you cannot invalidate a token serverside. Maybe the author has solid arguments for these claims, but the article does not do a good job of justifying them.

It will never fail that a new technology or technique comes out and there are a handful of bloggers who feel the need to write a hate piece. Some are well reasoned, even thoughtful, while others are just a way to gain viewers. I am not writing this article off as a useless hit-piece, but keep in mind that not every critical article on the internet should be taken as gospel.

As to your problem, just do whatever is most comfortable to you. Don’t want to use JWTs? Then don’t. This isn’t something you should fixate on when learning.