[Feature] OAuth vs 3 characters per Eve account

[DaneelTrevize]

Feature / Modification Request

Description

As per esi/esi-issues#303
For the initial SSO https://login.eveonline.com/oauth/authorize/? GET to also pass an optional character name to CCP, such that if the name is one of those on the account the user logs into, then that character is the one pre-selected in the authorisation dropdown. I.e on this page:
https://spectrefleet.com/media/image/fleets/fleet%20scopes.png

The app invoking SSO need not gain any additional data in the response, there should be zero risk of creating a means to determine which characters are on which accounts, this is simply a way to help sites to help their users not mistakenly try to SSO for the different wrong character name than they intend to & were sent to SSO for, when the redirecting app has a character name to propose (which won't always be the case).

Use case

A generic user has initially logged in to an app using independant credentials, or simple SSO without scopes, and is then required to authenticate again for a token with actual CREST/ESI scope included, because they wish to use role-restricted features such as an FC management tool (for which it would not be right to request every app user grant sufficient scopes for during simple SSO login).
The app can use this feature to forward the correct character name pre-selection to CCP for the character & scope confirmation page.

[cvweiss]

I respectfully ask that this is not implemented as it could be treated as a phishing attack vector. This method can be used to determine if characters are on the same account based on return of failure, or success, of the returning character and scopes.

[DaneelTrevize]

The app invoking SSO need not gain any additional data in the response, there should be zero risk of creating a means to determine which characters are on which accounts

So @cvweiss, please technically elaborate how it could possibly be used as a phishing vector, over the current functionality?

Currently the redirect to CCP occurs and a dropdown of up-to-3 characters is listed. All that's being requested is that a part of the redirect accepts a hint of which character name to pre-select, if it exists in the list. CCP wouldn't alter any response regarding whether the hinted name exists in that list or any other, the change is completely localised to the simple pre-selection or not of 1 UI element of a page that's completely only presented by CCP and consumed by CCP.

[GoldenGnu]

I really want this feature. It would be super useful when someone wants to add/remove scope for a specific character.

If the character is not in the dropdown, simply ignore the parameter.

I also fail to se how this could be exploited.

[CarbonAlabel]

Basic example of exploiting this functionality:

1. Suspect one of your users has an unreported/unregistered alt.
2. Next time the user needs to reauth, for whatever reason, set the proposed parameter to the suspected alt.
3. Assuming that the user will click on Authorize without stopping to check which character is selected, you will receive an authentication code which will resolve to the alt, confirming that your user does, in fact, own that alt, allowing you to discipline him as desired.

Moving from API keys to the SSO has severely impacted the UX of managing multiple characters, and improvements like this one would be worth much more than the minor risk of some people exploiting them.

Besides, we could use something like this to keep the API meta alive.

[GoldenGnu]

What about sending the ESI owner hash or even refresh token instead of the character name? Would that be better? I just need it to edit accounts, are there any other use cases where you don’t have a refresh token beforehand?

[DaneelTrevize]

Assuming that the user will click on Authorize without stopping to check which character is selected, you will receive an authentication code which will resolve to the alt, confirming that your user does, in fact, own that alt, allowing you to discipline him as desired.

This is a real stretch, you're saying an app should take responsibility for a user just blindly mashing through a CCP log-in screen, and need to already have a suspected alt name, and need to silently accept logging in to any character for any log-in request ... actually that part might mean it's outright impossible to abuse this while retaining any trustworthy authentication via SSO. You'd just be letting anyone who can log in to any account log into every account for your app.
And this whole case isn't much worse than the current 1/3 chance of accepting a dumb user just mashing through and giving away which character is the first one (alphanumerically) on their account.

improvements like this one would be worth much more than the minor risk of some people exploiting them.

[DaneelTrevize]

The original FR would still be so nice to have: a way to hint to users which character they should choose from the screen CCP presents them...

And again, no security risk, no means by which the referring app would know if that character was a valid option or not.

The wild idea that people will blindly SSO for any random site/app's sudden request and thus "leak" that a person in fact controls a character is an intrisic part of any login system, this FR is not related that that unreasonable fear/assumption of user stupidity.

[wvdvegt]

Another thing that has changed is that I do not see an option to give less scopes then required. For some tools like evemon this works nicely and restricts what the app can see/work with.

[DaneelTrevize]

Er, I don't think you should be assuming anything about the input your app gets back, even from SSO. Check a token's scopes using the verify URL and its Scopes response field. https://eveonline-third-party-documentation.readthedocs.io/en/latest/sso/obtaincharacterid.html

[wvdvegt]

I did not find a place/url to define what an app might read from me (like with the current system of api keys). Any ideas where I can set this?

[Aidansavage]

@wvdvegt you aren't able to without manually fiddling with the redirect URL. If an app provided options for limited scopes, it's because they coded that into the app itself.

[wvdvegt]

I would expect the list after the login (where you grant scopes) to be check/uncheckable (to limit it from what the app would like to have).

[Aidansavage]

If you arent comfortable authorizing an app for the full list of scopes it requests, and this is in spite of the 3PDev Agreement explicitly stating information gained via these authorizations can only be used for the purposes explicitly laid out by the app (mail apps basically cant go EVESkunk, to name an example) with violations leading to app termination, loss of developer privileges, and in bad enough cases, total account termination, then you have 2 choices currently:

1. not use the app, or
2. make a feature request to that application's developer to enable a picknchoose scope function.

Beyond those two choices, there is not much the SSO team can do right now. To continue discussing this, feel free to make a separate issue, or comment on an existing issue regarding that topic, and consider joining the Tweetfleet slack group ( https://www.fuzzwork.co.uk/tweetfleet-slack-invites/ ) and wander over to the #sso and #esi channels for more questions and discussions (and maybe political rants, he hasnt done one in a while though....).

[Seavert]

Scope selection was proposed in #8 (comment) , but its completely useless imo.
Scope list can be agreed in site/ui (from group names to direct checkboxes), then user must accept or reject resulted auth.
Every serious app ignores "tricky" edited callbacks with missing scopes and will resume to ignore them later.

[wvdvegt]

A solution i see is that an application offers sets of scopes for certain functionalities (like for each tab in Evemon) and combines them for SSO time.
For the application the scopes you define at the management page is the max it will use if all functionality is requested by the user if (s)he selects all avail functionality.
Did a quick test and it might be workable.