4 ms·
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 o
by peter_l_downs 14y ago
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?
- alanctgardner2 14y agoI've been wondering this as well. Maybe it protects against replay attacks? They're certainly a bit frustrating.
- johns 14y agoMy 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.
- mikeknoop 14y agoWhat'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.
- X-Istence 14y agoAs 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.
- johns 14y agoThe 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.