Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A guide to Oauth2

milapneupane.com.np

Post reply on HN
Print view View original

41–50 of 55 posts

Re: A guide to Oauth2

#41

Post by atoav »

ailideex wrote: post #17
atoav wrote: post #5

Earlier quoted context omitted.

Above that I think this is rude to my contacts: You can’t just go and upload random people’s data on plattforms of your choice . I get it – people feel like it is their contacts because they collected them, but they are not. This should be illegal.

So you don't store numbers of any of your contacts? You must have some insane memory ... but then again ... maybe memorizing random people's data should also be illegal... I mean did the people who told you those details give you permission to memorize it? I think not. And when you enter those memorized details into your browser or phone ... who gave you permission to do that?! Blatant GDPR violations.

If only there was some way to store contacts without uploading them..

Has it really come to this? If you open your phone now you usually have two offline options: to store contacts on the SIM card and to store them on the phone.

If you want backups and comfort without betraying your contacts you run your own nextcloud instance and store them automatically on there.

Re: A guide to Oauth2

#42

Post by icebraining »

nailer wrote: post #40
icebraining wrote: post #38

Earlier quoted context omitted.

> I wanted to stay in touch as they changed roles Sure, I might want that with a few coworkers, but not with my brother, aunt, friend's boyfriend or mother, tenant who rents my house, the shop who delivers butane, etc. Essentially 95% of my contacts are not relevant to a specific network, and dumping them indiscriminately seems not just bad form, but time wasting for me and them as well. > Are you sure you don't have…

> but not with my brother, aunt, friend's boyfriend or mother, tenant who rents my house, the shop who delivers butane, etc. Given that we are discussing LinkedIn, wouldn't you just not connect with them? Seems like a small cost for having to add that 5% of people manually.

There is no such thing as "just not connect with them". Once it gets an address, LI will hound you and them, trying to convince them to signup and connect (they even lost a lawsuit over this), and then they'll leak the contacts for every other criminal to abuse them.

Yeah, I'll manually add a few people to avoid imposing that on myself and others.

Re: A guide to Oauth2

#43

Post by cbaleanu »

pierreyoda wrote: post #6

I'm currently in the middle of implementing an OAuth 2.0 authorization server following the RFC draft of the best current practice [1]. It's been a huge pain navigating all the interlinked (and sometimes contradicting) RFCs around, especially with a distinct lack of resources for actually implementing an authorization server. RFC6749 does not suffice on its own since it says nothing about authentication or tokens pay…

Me and my team are happy users of keycloak[0] running in a docker swarm, pretty nice so far anf very good documentation. Building your own authorization/authentication solution is really nice as you learn a lot, but there is a lot of work involved. [0] https://github.com/keycloak/keycloak

Re: A guide to Oauth2

#44

Post by webhamster »

kerkeslager wrote: post #37

OAuth2 isn't a standard protocol. A real standard protocol is one where you can build a library around it and then use that to communicate with anyone else who conforms to the standard. OAuth2 is more of a description of the various homegrown authentication methods different websites have tried to create. None of those websites want to reimplement their auth to conform to the standards, so they just add their auth to…

FYI, the IETF plans to deprecate the Resource Owner Password Credentials Grant you are talking about [1].

[1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics

Re: A guide to Oauth2

#45

Post by webhamster »

webhamster wrote: post #44
kerkeslager wrote: post #37

OAuth2 isn't a standard protocol. A real standard protocol is one where you can build a library around it and then use that to communicate with anyone else who conforms to the standard. OAuth2 is more of a description of the various homegrown authentication methods different websites have tried to create. None of those websites want to reimplement their auth to conform to the standards, so they just add their auth to…

FYI, the IETF plans to deprecate the Resource Owner Password Credentials Grant you are talking about [1]. [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics

Quote:

   The resource owner password credentials grant MUST NOT be used.  This
   grant type insecurely exposes the credentials of the resource owner
   to the client.  Even if the client is benign, this results in an
   increased attack surface (credentials can leak in more places than
   just the AS) and users are trained to enter their credentials in
   places other than the AS.

   Furthermore, adapting the resource owner password credentials grant
   to two-factor authentication, authentication with cryptographic
   credentials, and authentication processes that require multiple steps
   can be hard or impossible (WebCrypto, WebAuthn).

Re: A guide to Oauth2

#46

Post by sjroot »

utopian3 wrote: post #33
sjroot wrote: post #12

Earlier quoted context omitted.

I’m actually working on the same thing but in Rust. If you ever want to compare notes sometime, give me a shout out. I’m actually kind of glad the documentation found via google searches (save one collection of Medium articles) has been disappointing. It has motivated me to look directly at the specification which I’ve found to be the most valuable resource thus far.

Which medium collection? I’d like to read to refresh my knowledge

https://medium.com/google-cloud/understanding-oauth2-and-bui...

Re: A guide to Oauth2

#47

Post by derangedHorse »

blr246 wrote: post #29

It's worth mentioning that it's a bad idea to invalidate refresh_token grants ever during the lifetime of an authorization. I've seen APIs do this immediately upon sending the response to the token endpoint, which makes the system unusable due to the frequency of network transmission errors that would result in having to contact the resource owner to grant access again. Even an expiry after days and years is only lik…

"sending the response to the token endpoint" Which response?

"makes the system unusable due to the frequency of network transmission errors that would result in having to contact the resource owner" What kind of network transmission errors are you getting? And at what quantity? This shouldn't be too difficult to do

I disagree and think refresh_token expirations do add to security and believe it is the client's job to handle any difficulties that can come with the expiration period

Re: A guide to Oauth2

#48

Post by kerkeslager »

webhamster wrote: post #44
kerkeslager wrote: post #37

OAuth2 isn't a standard protocol. A real standard protocol is one where you can build a library around it and then use that to communicate with anyone else who conforms to the standard. OAuth2 is more of a description of the various homegrown authentication methods different websites have tried to create. None of those websites want to reimplement their auth to conform to the standards, so they just add their auth to…

FYI, the IETF plans to deprecate the Resource Owner Password Credentials Grant you are talking about [1]. [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics

Okay, but why was this ever put into a standards track in the first place? This isn't an obscure error, it's the kind of glaring error that shows that a security standard is being designed by people who know next-to-nothing about security. Recently, when I implemented authentication to a site that used Resource Owner Password Credentials, my client's CTO reported it as a bug because he (correctly) noticed the security flaw. If you're making this sort of error, you have no business writing production authentication code, let alone standards for production authentication code.

And this is only the most glaring error. Another example: there's no specification for how to generate tokens, and I've implemented OAuth for platforms that return tokens which look suspiciously like UUIDs. Not only are UUIDs explicitly recommended against as credentials by RFC4122[1] because people could reverse engineer your UUID generation, but collisions have occurred in practice[2] without any reverse engineering, meaning that a user could authenticate as another user without even hacking.

And to clear, I'm not a security auditor and I've never done a security audit of any OAuth implementations except my own. These are problems I discovered by treating other people's OAuth implementations as black boxes, all of them compliant to the so-called "standard". Security is hard, and with so little specified, I imagine the majority of OAuth implementations in the wild are actually not secure.

[1] https://tools.ietf.org/html/rfc4122#page-16

[2] https://en.wikipedia.org/wiki/Universally_unique_identifier#...

Re: A guide to Oauth2

#49

Post by derangedHorse »

atoav wrote: post #5
dvh wrote: post #2

> You want to add all your contacts in Gmail who are in skype Never once in my lifetime I wanted to do that. For any two services.

Above that I think this is rude to my contacts: You can’t just go and upload random people’s data on plattforms of your choice . I get it – people feel like it is their contacts because they collected them, but they are not. This should be illegal.

It would be ridiculous to make something like that illegal. Contact information shared with an individual DOES give that individual the freedom to use the information how they'd like. Hopefully whoever shared their contact information in the first place is okay with their information being stored with Apple or Google since that is the default way many people back up their contacts. If the contact sharer is not okay with it the onus is on them to vet who it is they're sharing their information with.

Re: A guide to Oauth2

#50

Post by rhacker »

pierreyoda wrote: post #6

I'm currently in the middle of implementing an OAuth 2.0 authorization server following the RFC draft of the best current practice [1]. It's been a huge pain navigating all the interlinked (and sometimes contradicting) RFCs around, especially with a distinct lack of resources for actually implementing an authorization server. RFC6749 does not suffice on its own since it says nothing about authentication or tokens pay…

I'd love to see RFCs return back to one goal, one RFC. These days we have RFC ivory towers where they make a base spec, and 7-8 implementation option specs. All separate RFCs. Very horrible. (edit a goal being a complete thing: oauth2)
Post reply on HN