For context, in order to star projects on user's behalf you'd need to request public_repos scope[1], so the UI will look like this: https://github.com/login/oauth/authorize?client_id=33a703d01... (I used a random client_id from google search). As you can notice, the UI does not mention stars at all.

[1] public_repo: Limits access to public repositories. That includes read/write access to code, commit statuses, repository projects, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories. (https://docs.github.com/en/developers/apps/building-oauth-ap...)

I believe github doens't even have a scope that gives read access but not write access. So we users have been trained to just grant that scope to people who really only need read access, because it's the only thing that works. And in general trained not to even pay attention to those scopes anymore -- on github specifically -- because they are such a mess, and third-parties routinely need scope overreach to do what they want.

So I do think github is broken here in a way that predictably leads to problems like above. They need better more granular scopes (and have for years; I don't understand why with their resources they haven't prioritized it), and then they need a better UI for making sure the user understands what they are granting, differentiating between read vs write, etc.

Without that... it's only a matter of time until something much worse happens, like someone abuses a scope to insert malware in someone else's repo. I would not be surprised if it's happened already but hasn't been publicly known.

BUT, also... you sign up for a service that will for-pay get around captchas for you so you can automate access to a site where the captchas are intended to prevent automated access, and then you're just shocked that this service would do something unethical...

Wow, this is really bad. The words "read and write" are hidden unless you click on the arrow next to "Repositories".

I'm surprised this hasn't been used for malicious purposes until now.

That [1] is how "ask only for e-mail", "proper" "just" SSO looks like.

While sure it isn't immediately expected to access "stars" feature when you give public repo access...

...you're giving it fucking repo access. That's WAY more (on a "how bad it can be if you get hacked") permissions than just starring.

> That includes read/write access to code [on public repos owned by the user]

What the hell, imagine logging-in with your account, you as a maintainer of a large public repo, and failing to understand clearly that you are giving a 3rd party the possibility of commiting on your behalf.

Seriously there should be a big red warning on all scopes apart from the "none" one.

No this is standard procedure. You have to register the permissions you are going to request to github. But github is not going to inspect your app and checks that they are indeed required.

Github's responsibility is to ask consent to the user and display all the requested permissions. If the user accepts then Github has done its work.

This is how all oidc providers work.

It is not how Oauth2 needs to work, or should work. OIDC is (or should be) about the user's identity only. It's for third partiets to know who you are, not for third parties to act on your behalf.

If the screen to give a 3rd party permission to identify you, looks like the screen to give a 3rd party sweeping permission to act on your behalf, that's github's responsibility and problem.

It would also be a good reason for responsible 3rd parties to ditch github for identity, if they don't address it.

(Another matter is that the big public OIDC providers' eagerness to let you use them might be a lot about tracking.)

OAuth is definitely about scope.

See the latest draft for OAuth Rich Authorization Requests (“work in progress”): https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html

edit: you might be mixing up / conflating Open Authorization (an authorization standard - authorization scopes are in scope) with Open Identity (an authentication standard - authorization scopes are out of scope)

edit 2: It probably doesn’t help disambiguate which auth is which when the same company is providing both the authentication service and the authorization service.

Why is everyone linking this draft? It's got very little to do with what we're discussing.

Yes, of course OAuth is about scopes! But OIDC is a protocol built on top of OAuth2 which is for identity only. You get no permission to act on the user's behalf from the OICD scopes, only read access to information you need to identify them.

This whole problem only happened because

1. Github is an OIDC provider, allowing you to identify yourself to websites around the world.

2. Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site.

3. The one looks too much like the other. OP probably thought he was just showing ID, but what he was doing was giving the site sweeping permission to act on his behalf, which the site promptly misused.

The problem here starts already at 2. That anyone can create an integration and ask for OICD scopes, is one thing, but why do they make it so easy to hand out their own scopes? There are not that many third party apps that have a legitimate need to act on the user's behalf. Maybe some continuous integration stuff? But even that should only have access to the user's own repositories. Nothing I can think of has a legitimate need to go around starring random repositories.

> That anyone can create an integration and ask for OICD scopes, is one thing, but why do they make it so easy to hand out their own scopes?

That was probably one of the advantages of shoe-horning authentication (OpenID) with the existing authorization standard (OAuth).

> Why is everyone linking this draft? It's got very little to do with what we're discussing.

> … Github ALSO uses OAuth2 to delegate permissions to the user's stuff on their own site

> … But even that should only have access to the user’s own repositories.

Seems like Rich Authorization Requests are exactly what we are discussing.

Give it a skim (or a read).

You don't need RARs to limit access. It's just a proposal to standardize very fine-grained control access.

This is not very fine-grained. It would be perfectly possible to gate access to social features of github (such as starring) behind a plain old scope. Distinguishing "access to all your own repositories" from "access to anything else on github, as you" also is not a fine-grained difference.

Sure, but the extra “location” and “action” objects within the proposed “authorization_details” JSON object do seem compelling when compared to just a single “scope” string.

Speaking of shoehorning things, it doesn't look particularly "Open" to me that website owners are free to pick a limited number of authenticating authorities, instead of letting the user to pick their own.

(Imagine if e-mail adresses were considered "invalid" in forms if not from Gmail or Outlook !)

It was especially bad with last years Advent of Code, where going through OpenID (or was it OAuth ?) was the ONLY way to join, and with only 3 options listed, none of which I wanted to use !

It is interesting though, most people use it just to avoid creating a new username/password on a random site. Usually there is no intention to grant access to any data maintained on the IDP's site. I know the concept of granting such access is the whole point of OAuth but honestly seems like a rarely needed use case.

The website (oauth client) has to tell the IdP (oauth provider) what level of access they want to have on the user's behalf. OIDC is an extension of oauth that focuses on the basic identity aspects. (It basically just standardizes the user info and how to ask for it).

So an app could request only the non-data-access OIDC scope, or an IdP could enforce that it only allows apps the OIDC info.

On top of that is the user consent. What has been pointed out in threads here is that the IdPs are making the UX for basic OIDC consent too similar to the UX for consenting to privileged data access.

And of course if an oauth token is being abused, the IdP should ban the client app first, not the user...

Yes, I know how it works. My assertion is it really should not work this way by default. Providing identity (i.e. email address) to a random website is much different from providing them with access to sensitive data (often subtly shown in the signup dialog).

It is good to take a step back from the tech and think about it from the user's perspective.

OIDC is build on top of OAuth and OAuth is all about scopes and authorizations. You can split the two but OIDC is designed to request id info and access authorization in the same transaction.

> This is how all oidc providers work.

No. When an app is registered with them, a provider does check if the scopes requested have a reasonable business purpose. Many registration forms even ask you to explain why you need the scopes requested. This is similar to how Apple App store does review.

Many OAuth providers also check periodically if one of their registered apps is used for any pattern of abuse.

Furthermore, a client can omit scope and leave it up to the server to decide whether to fall back to a default scope or fail the oauth request.

This patently false. Google for example requires an oauth app registration and approval process. It's one of their annoying faceless processes that developers must go through, but exists for good reason.

> the issuer doesn't just hand out scopes like candy

GitHub isn’t doing the handing out, it is the user doing the handing out.

I don’t blame the user, as a rule, but in this type of scenario, the user (a consumer of development tools) shouldn’t be excused, in my opinion.

This would be like a doctor complaining for getting sued for malpractice by a patient of a nurse under the doctor, while the doctor neglected to review the patient chart and neglected to take the time to speak with the nurse.

caveat emptor

All that said, I would hope that bad actors that get caught, effectively phishing for GitHub credentials, using a technique like this end up being banned from GitHub.

As I said, before the app even can ask for a scope, github has to give that app permission to ask for a scope.

I have written some integrations against altinn, the Norwegian government's portal for basically anything official. Getting approval for a scope there is a process, as well it should be. If I write an app that lets users send construction applications to the local municipality on the user's behalf, do you think I can just sneak in a request for permission to change the user's address, name and bank account registrations as well? No. There are scopes for that (I assume), but my app won't get to request them, no matter how much the user would be willing to give them.

And "caveat emptor" is not the threat model you can get away with on the web. Sure, it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials. But I'm a user too, and it would NOT be fun as a user.

> And "caveat emptor" is not the threat model you can get away with on the web.

Caveat emptor is not a threat model, it is a risk mitigation.

It is arguably the only mitigation directly in the hands of the consumer.

And that the modern phrase is from a 2000+ year old “dead language” should certainly speak to the longevity, utility, and effectiveness of that mitigation.

> it would be great for me as a dev if I could just disavow responsibility for cross site scripting attacks and other attempts to misuse the user's credentials

thankfully there are standards and RFC’s that indicate best practices that recommend that these security risks be considered and mitigated

edit: see Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html> for the “work in progress”

When you run a service on the web, it's not enough to protect yourself. You must protect your users to the best of your ability. Threats against your users must be part of your threat model.

If not, you won't keep them. They will leave. And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".

> When you run a service on the web, it's not enough to protect yourself

Nothing but agreement there.

Can you identify a specific recommendation by the IETF or W3C that was ignored, in this case?

> And saying "caveat emptor" will be about as effective at preventing that as saying "wingardium leviosa".

I had to look up that apparent reference to Harry Potter, but I disagree.

Educating your users about phishing risks, aka “caveat emptor” in this context, is explicitly a best practice for mitigating these kinds of security risks on the open web.

Github is not the Norwegian government though. Github is not a gateway to public bureaucracy or to public services. It provides repository hosting, project management, and integration with build tools and similar services. Fostering a wide ecosystem is a core part of their business strategy, and as such applications are only validated superficially. Also, it operates at a scale that makes such validation infeasible.

Furthermore, the audience of Github is decidedly more technical than a government website or social media platforms. IMHO it can be expected that its users step through authentication flows a bit more carefully.

Github should act more decisive when applications turn out to be malicious though. The Laissez-faire policy of frictionless integration of applications has to be balanced with effective procedures to react to malicious uses.

GitHub is Microsoft. And as a provider of developer tools, weird to see such apologism for their inability to structure oauth scopes correctly and provide effective unambiguous UX for user consent.

Let alone banning the user instead of the client app...

> Also, it operates at a scale that makes such validation infeasible.

It's a choice to be at such scale that github cannot validate 3rd party auth. Gothub should accept fault for these incidents if they are not going to validate their partners.

It's the exact same as third party sellers shipping counterfeits on Amazon. Choosing to achieve massive scale leaves quality, validation, and consumer protection behind.

Did you see how apparently inoffensive the permission granting sign in is? It looks very similar to a standard login. It would be very easy for anyone, regardless of knowledge, to blow right by that. The lack of distinctive labeling as not a standard sign in operation is really irresponsible on the part of GitHub here.

API scopes could totally use some mandatory standards. You can't make a digital ocean token to simply edit DNS without full delete-all-your-VM's & charge thousands access.

Similarly we shouldn't bill for service accounts, especially when they're documented as the way to limit API token access. It's self-defeatist like taxing longer passwords.

Sounds like a good use case for Rich Authorization Requests <https://www.ietf.org/archive/id/draft-ietf-oauth-rar-18.html>

Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had).

Therefore if you want them, pay up or do it yourself.

> Finetuned permissions cost to implement. GitHub doesn't have them (maybe we wouldn't have seen this post if it had).

They exist for github apps, and they're being rolled out for PATs alongside forced expiration: https://github.blog/2022-10-18-introducing-fine-grained-pers...

Not sure there's any way for them to happen for oauth apps though. And even if they do, they're opt-in for the app and the old broad scope will remain. At best the broad scopes would only be accessible to old apps grandfathered in but that ain't much (there's probably a billion abandoned oauth applications you could purchase for that grandfathering).

Fine, put that behind my $x/mo account + service accounts.

$x/mo * Service accounts is dumb.

That's not a practical suggestion, since GitHub isn't self-hosted or open-source.

Well, it is PITA to implement so I'm not surprised really...

If stars are so important that any program that can auto-check stars is inherently fraudulent, then why allow any official third party API the ability to click on stars? Shouldn't that always be something you explicitly have to click?