Hacker News Reader

Comment by peter_l_downs | Hacker News Reader

If you decide not to support the HMAC stuff, writing a server implementation for OAuth 2.0 isn't really that bad. Something I've been confused about since day one is the need for refresh token. If an attacker is able to sniff the auth token, wouldn't they be able to sniff the refresh token, too?

View on HN

My understanding, and it may be wrong, is that if an attack walks off with your data, then wouldn't be able to refresh the access token you have on hand without the client ID and secret and so the extent to which they could compromise the authorized accounts is limited in time.

What's worse is when OAuth providers force the refresh tokens to be refreshed! Many OAuth providers are now requiring user-action (ie. re-walk through the oauth popup) every x months to get new refresh tokens.

As a user I am actually okay with this. That way if I haven't visited a website in a long time, then most likely they should no longer have access to my account.

Maybe I've long moved on and forgotten about that one site that I authorised and now they are using my data in a way that I wouldn't approve of.

The tricky part is for services like IFTTT (where I used to work) and Zapier (where the GP works) where you do want an authorization to be indefinite and not require user interaction because it's a background job.

I've been wondering this as well. Maybe it protects against replay attacks? They're certainly a bit frustrating.

Reply on news.ycombinator.com