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

31–40 of 55 posts

Re: A guide to Oauth2

#31

Post by tialaramex »

rypskar wrote: post #25
icebraining wrote: post #24

Earlier quoted context omitted.

Well, the GDPR doesn't apply to "a natural person in the course of a purely personal or household activity", so they can upload them, assuming they're personal contacts. For contacts of clients and such, probably yes, since whatever conditions for allowing their processing in Gmail probably also apply to Skype (and vice-versa). But it might not if for some reason the other service offers less security or control over…

That makes sense from the uploader side. But can the service store and use data about me because you uploaded it? In this case I have only added my data to Gmail, and never allowed Skype to have it and have not accepted the terms from Skype.

Maybe. It can probably use this to help the user who uploaded it do something, since for that purpose it's evidently suitable - if I upload the claim that rypskar has the nickname "Dog boy", their phone number is +1-555-555-1234 but they live in New Zealand, then providing that information back to me seems pretty harmless even if it is bogus.

But if they take this data and then try to do something else with it, whether that's contact rypskar or give the data about rypskar to somebody else - that's going to run into lots of GDPR problems around correctness (the data processor is obliged to take reasonable steps to ensure the data is accurate and fix problems on request) and as you identified with permissions (did rypskar authorise this? How do we know? Who even is rypskar?)

Re: A guide to Oauth2

#32

Post by awinder »

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…

I don’t think I saw a support ticket in years around refresh tokens and we definitely expired them to avoid storing an infinite history of the things. And also a nagging sense of not increasing account token leakage.

Tl;dr: I don’t know kids, seemed fine to me, world didn’t end

Re: A guide to Oauth2

#33

Post by utopian3 »

sjroot wrote: post #12
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’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

Re: A guide to Oauth2

#34

Post by checker »

perttir wrote: post #11

Im not sure there ever will be a complete complete oauth2 considering everyone who implement it have their own flavor of it.

Yeah this is far from complete. It doesn't even mention OAuth scopes or standard flows. A more appropriate title would be "A Beginner's intro to OAuth2". This is way better:

https://medium.com/@darutk/diagrams-and-movies-of-all-the-oa...

Re: A guide to Oauth2

#35

Post by microcolonel »

sjroot wrote: post #18
pierreyoda wrote: post #15

Earlier quoted context omitted.

Oh yeah definitely! Rust would be awesome but I think I'd want it to be as accessible as possible. Tagged unions and proper error handling would make it much saner though that's for sure.

I was initially going to do it in TypeScript, as the clients that will be interacting with it are TypeScript. Can’t really go wrong either way, but yeah, I’ve enjoyed exploiting Rust’s type system!

Be careful to do the hard stuff in workers, otherwise your throughput will be limited by one core.

Sorry if that's so basic of a consideration that it's insulting, but I've seen it done before.

Re: A guide to Oauth2

#36

Post by darkerside »

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…

I've always believed it should be the responsibility of the consumer (perhaps with the aid of client libraries) to properly handle the refresh lifecycle. I'm not a fan of password rotation, generally speaking, but it's because humans are terrible at remembering and creating complex passwords. Software processes don't have the same problem.

Re: A guide to Oauth2

#37

Post by kerkeslager »

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 the standard. This is standards conforming to practice, not practice conforming to standards.

Can you imagine if the HTTPS standard had to have 100 different variations to connect to 100 different sites on the net, with no way to detect which one was in use, so that you had to have the variations hardcoded for every site you visit? Because that's where we are with OAuth.

Worse, some of the practices which are now RFCs are complete garbage. The grant type Resource Owner Password Credentials[1], for example, requires that the third party server ask the user for their username and password. This defeats the entire purpose of OAuth. Don't give me some crap about this being useful for first-party servers: there are way simpler and more secure ways to authenticate first party servers. OAuth is for authenticating users with third-party servers, and you should absolutely, unequivocally not be letting third party servers ask the user for their username and password. This normalizes putting your passwords for one site into another site for nontechnical, which is outright irresponsible and unethical.

Yet in the handful of times I've authenticated with OAuth as a third party, more than one of the first-party sites I was authenticating with used this method, putting the onus on me to correctly handle their usernames and passwords. The reasons are obvious: 1. Doing it the insecure way is easier because it allows sites to avoid implementing an SSO portal to handle their own passwords and grant initial access (which, incidentally, isn't included in the standard protocol at all AFAIK, despite being necessary to make it work) and 2. The IETF somehow thought it was a good idea to give this awful security practice an air of validity with an RFC.

The OAuth2 protocol standard is a tire fire which is unsalvageable at this point. We need a new standard that is actually a fully-specified standard, with a single, clear path from start to finish, including the initial use of passwords to obtain tokens, which serves the single purpose of allowing third party services to authenticate in a secure way.

[1] https://tools.ietf.org/html/rfc6749#section-1.3.3

Re: A guide to Oauth2

#38

Post by icebraining »

nailer wrote: post #28
icebraining wrote: post #26

Earlier quoted context omitted.

> I wanted to see who I knew when LinkedIn first came out. I'm curious, why? I sign up to different services (reluctantly) because I want to communicate with people I can't yet. Occasionally I might have some contacts on two networks, if there's some specific feature I want to use, but it's rare.

I wanted to stay in touch as they changed roles. I still do. > Occasionally I might have some contacts on two networks, if there's some specific feature I want to use, but it's rare. Are you sure you don't have business contacts who are also in your email address book?

> 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 business contacts who are also in your email address book?

Yes, but they are a small subset of both circles.

Re: A guide to Oauth2

#39

Post by afrodc_ »

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…

Would OpenID Connect not satisfy this requirement? It's an authentication wrapper of OAuth2

Re: A guide to Oauth2

#40

Post by nailer »

icebraining wrote: post #38
nailer wrote: post #28

Earlier quoted context omitted.

I wanted to stay in touch as they changed roles. I still do. > Occasionally I might have some contacts on two networks, if there's some specific feature I want to use, but it's rare. Are you sure you don't have business contacts who are also in your email address book?

> 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.

Post reply on HN