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.