Re:OAuth 2.0 Authentication Vulnerabilities
by mwcampbell on Saturday March 27, 2021 @10:25PM
(#26607445)
I'm currently trying to decide if OAuth is overkill for something I'm working on: a first-party browser extension for a SaaS. The extension needs to authenticate the user with the SaaS on installation, then make API calls to the SaaS on the user's behalf. In theory, OAuth is a good idea because it's a standard, as opposed to some ad-hoc system that I cook up myself. But if I try to use an off-the-shelf OAuth provider implementation in the SaaS, it's obvious that I'm not using it for its intended purpose, because when a user goes through the OAuth authorization flow, they get a screen asking whether they authorize the app to access the service. But in the user's mind, the app (the browser extension) is part of the service. So, does that just mean I need to tweak the OAuth provider? Or is this a hint that I should go with a simpler solution?
[ Parent
| on HN ]
Re:OAuth 2.0 Authentication Vulnerabilities
by TriNetra on Sunday March 28, 2021 @02:14AM
(#26608390)
You can use HMAC [0]. Create a UI to collect username/password and make an API call to login endpoint, which should return sessionId/secret. going forward sign API requests using the HMAC protocol without ever revealing the secret on the wire again.
0: https://aspsecuritykit.net/guides/implementing-hmac-scheme-t...
Re:OAuth 2.0 Authentication Vulnerabilities
by tptacek on Sunday March 28, 2021 @01:16AM
(#26608167)
OAuth is overkill for what you're working on. You generally won't go wrong with the rule of thumb that you do the least amount of cryptography your design requires you to. You should be dragged kicking and screaming into more of it. In this case, generating a long random token and using that to authorize requests has all the basic security benefits of an OAuth bearer token and almost none of the attack surface. Long random tokens are the most overrated technology in authentication.
A general rule of thumb w/r/t/ OAuth is that it starts to make sense when you are delegating authorization to other companies that share your users. Think "TweetLater".
“Long random tokens are the most overrated technology in authentication.”
Just so I follow, did you mean underrated…?
Re:OAuth 2.0 Authentication Vulnerabilities
by tptacek on Sunday March 28, 2021 @01:01PM
(#26611976)
Yeah, sorry!
Re:OAuth 2.0 Authentication Vulnerabilities
by laurent92 on Sunday March 28, 2021 @04:35AM
(#26608830)
But then you need to implement token revocation, by the host, the user or the client, and find a cryptographically-secure way to generate the key.
Re:OAuth 2.0 Authentication Vulnerabilities
by wolf550e on Sunday March 28, 2021 @05:13AM
(#26608951)
To revoke the token, the server deletes it from the database.
If you have the token, you can ask the server to delete it from the database. The cryptographically secure way to generate it is to read 32 bytes from getrandom(2) or from /dev/urandom.
you basically told somebody to roll his own crypto. that is a stupid idea. using refresh tokens and access tokens in a standard way is way more secure than rolling your own, this stuff is already pretty hard.
of course one could go with a simple cookie login, but when it comes to external apps, that's not always a good idea, especially not if you need to revoke specific applications.
so your general rule of thumb is pretty stupid.
In what way is getting 32 bytes from /dev/urandom rolling your own crypto?
Re:OAuth 2.0 Authentication Vulnerabilities
by hirsin on Saturday March 27, 2021 @10:43PM
(#26607501)
So called "first party apps", those that are first party to the IDP, can often be considered as pre-consented. So the consent can be skipped - it's why you don't need to consent to use Excel or Gmail.
If you have no other features ever planned around authentication or authorization, and no other planned client software, you can build what you want in directly.
OAuth provides an abstraction between the authentication, permission grant and user consent and getting a token representing authorization, and provides additional best practices for things like securing web and native app access, token revocation, token introspection, etc. You probably want to be in the business of improving your SaaS, not designing a secure access system.
That isn't to say you can't build something now with the idea that you will migrate away from that once you hit an inflection point in complexity due to new features.
Re:OAuth 2.0 Authentication Vulnerabilities
by tptacek on Sunday March 28, 2021 @10:13PM
(#26617026)
I don't think it's at all the case that OAuth builds baseline best practices regarding authentication into applications. OAuth makes --- in fact, essentially is --- a series of concessions to enable delegated authorization, which is a much harder problem than simple authentication or single-site authentication. When you use OAuth in simplistic scenarios, you're importing all the challenges (and, as this page, the RFC, and a zillion other sources show, vulnerabilities) that OAuth has to deal with to make delegation work... but for no reason.
I'd generally caution against using OAuth until you know you need it.
Re:OAuth 2.0 Authentication Vulnerabilities
by throwbacktictac on Saturday March 27, 2021 @10:45PM
(#26607505)
I think it make sense to have a oAuth service for it. Like you said, it standard and straight forward. If you will have third party consume your users API you won't have to put too much effort into coming up with a different scheme.
google and TDAmeritrade authenticate their 1st party services with oAuth and it logically makes sense to me.