Authentication without any scopes doesn't result in a refresh token

[CarbonAlabel]

Description

When simply using the SSO to confirm the identity of a character without requesting any scopes (using the authorization code flow), exchanging the authorization code will not yield a refresh token (a null value will be returned).

Use case

Periodically checking if the character has changed hands by comparing the CharacterOwnerHash.

Current Return

{
    "access_token": "YYzip1Vtitkd7C2GQraGn6gbvE8FYW4AsJPLnlwpwE6PJcsaWIvrqS3aXlrNZ06HLUQ9ipdDiuMoxpYAUCTQQ8CSzpoh",
    "token_type": "Bearer",
    "expires_in": 1200,
    "refresh_token": null
}

Expected return

{
    "access_token": "YYzip1Vtitkd7C2GQraGn6gbvE8FYW4AsJPLnlwpwE6PJcsaWIvrqS3aXlrNZ06HLUQ9ipdDiuMoxpYAUCTQQ8CSzpoh",
    "token_type": "Bearer",
    "expires_in": 1200,
    "refresh_token": "aRefreshTokenShouldBeReturnedHere"
}

[ISDThalackDalhar]

Not sure if this is a bug, this is documented here: http://eveonline-third-party-documentation.readthedocs.io/en/latest/sso/refreshtokens.html

"If any valid scope was requested"

Without any scopes requested, you are requesting an authentication cycle only, which doesn't have a lifetime (which equals the "Authentication Only" option on the developers site). If you want an authentication cycle with a refresh token, you can always request the publicData scope.

[CarbonAlabel]

Neither am I, which is why I haven't marked it as such. Keep in mind almost all of that documentation was written by third-party devs based on how the services were behaving at the time, making them a pretty bad point of reference for figuring out if something is working as it should be.

The problem here is that a refresh token not being returned in this special case breaks the (reasonable) assumption that using the implicit flow will give you access during a single 20 minute window, and using the authorization code flow gives you access forever/until revoked.

[stebet]

Currently we don't issue Refresh tokens for auth-only requests (ones requesting no scopes). If this is something that is sorely needed we'll look into changing that behavior.

[Aidansavage]

Would a "no data" scope be a potential solution? Basically something that lets you avoid constantly asking a user to re-authenticate in the event you only need to prove that they have an eve character (such as forums and the like), and would use that in lieu of an additional account login.

[itshouldntdothis]

The publicData scope might be what you're looking for.

[Xaroth]

Would a "no data" scope be a potential solution?

This is what the publicData scope does, it doesn't give any further access apart form what is publicly available, but it does generate a refresh token for persistence

[edit] @itshouldntdothis beat me to it..

[ddavaham]

Please do not use the publicData scope. It is a CREST scope and will be faded out in May 2018. This is poor advice

EDIT: Spelling

[itshouldntdothis]

It is a CREST scope and will be faded out in May 2018.

It had been discussed with TeamTechCo and I was told it wouldn't be removed due to the mentioned use case around character_owner_hash.

[Aidansavage]

I believe with the addition of being able to inspect/introspect/whatever the term ghostrider used was, for the tokens, regardless of type, this may not be an issue anymore. Think the owner hash and character information attributes may be included with the new JWT thing he's been working on. I've been awake for longer than I should be right now, so I could be entirely wrong. I'ma poke him and see if we can get some accurate input.

[Seavert]

While scopes have fair warnings in auth page, character owner hash is provided silently and 99% users not even guess about thatt. Moreover, empty authorization seems as showing your visiting card and exposing your account-related data is impolite. My suggestion:

1. Remove hash from tokens.
2. Add ESI endpoint with new scope to provide hash there. This can create clear environment and resolve issue above by choice of hash scope.

[GoldenGnu]

The owner hash is unique for each character, it can not be used to identify characters on the same account.

[Aidansavage]

Owner hash is also meant for us, 3rd party devs, to know whether ownership of a character using our services has changed. This is relevant for things such as alliance services. It isn't information an end user has a use for, or any reason to attempt to hide it.

[CarbonAlabel]

Based on a recent conversation from Tweetfleet Slack, I've learned that the v2 SSO behaves as requested in this issue, returning a refresh token even when no scopes are requested.

@stebet can we get confirmation that this is intended behaviour that's here to stay, and not some kind of accident?