These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

What's with Support->Third-party-apps?

First post
Author
Salgare
Violence is the Answer
Wormhole Society
#1 - 2016-07-08 14:48:58 UTC  |  Edited by: Salgare
What is the intended use of Third Party Appplications?

Is it this?
Blacksmoke16
Resilience.
#2 - 2016-07-08 15:12:48 UTC
Third party applications page just lists the applications you logged onto with each character and allows you view/revoke the permission scopes you accepted when you sign onto that application with the SSO.

Salgare
Violence is the Answer
Wormhole Society
#3 - 2016-07-08 16:33:23 UTC  |  Edited by: Salgare
Blacksmoke16 wrote:
Third party applications page just lists the applications you logged onto with each character and allows you view/revoke the permission scopes you accepted when you sign onto that application with the SSO.


I have not analyzed it closely, but during development I noticed that it maintains separate entries for the same application if that application has authenticated requesting different scopes. One can not disallow some subset of these.

I can freely delete these from services->3rdparty, but as soon as I sso back in they reappear. I have not checked, perhaps they actually disallow a current hot SSO connection/session ... but why when the user can simply logout of the SSO session, likely a lot easier (i.e. phone in hand, or running application requiring sso in the first place) than going to where-the-heck-was-that->support->3rdpartyapps to basically ... logout.
Blacksmoke16
Resilience.
#4 - 2016-07-08 16:39:09 UTC
I want to say logging out of the application itself does just that, logs out of of that application. The scopes/tokens generated from that app are still there. I have not tested it but if an app requests say location endpoint, and you log out of sso that permission is still there, ie the site can still know where you are even if you aren't logged into the site; unless you revoke that app in the Third Party Applications page.
Salgare
Violence is the Answer
Wormhole Society
#5 - 2016-07-08 17:07:10 UTC  |  Edited by: Salgare
Blacksmoke16 wrote:
I want to say logging out of the application itself does just that, logs out of of that application. The scopes/tokens generated from that app are still there. I have not tested it but if an app requests say location endpoint, and you log out of sso that permission is still there, ie the site can still know where you are even if you aren't logged into the site; unless you revoke that app in the Third Party Applications page.


Yes, I assume the application still has access to your location, until the OAuth access_token times out (currently 20 minutes I believe). Hmmm, I suppose an ill-behaved OAuth implementation could continue to use the refresh_token regardless of if the user logged out.

Thinking about this more, I believe that's the case in my current app, the Web app framework has it's own "session" support to the browser, but that is totally isolated from my "client" to ccp. There is nothing in the browser session destroy that enforces that the aliased client to cpp is destroyed. (should be consider a bug in my code, which I will fix)

Now I'm real interested to see if that will drop my servlet to cpp connection.

wow, buyer beware I suppose.

What normal user is going to understand this? Perhaps cpp should reconsider the current infinite life of the refresh token. Make it like 24 hrs, a good long time, but not too long

eta:

lol, I suppose they already have ... it's called downtime

Thus we are saying the useful purpose of support->3rdparty is for the paranoid user to go there when they are done for the day and kill all apps assuming they are ill-behaved and might misuse their sos authentication until the next downtime.

Which makes me ask, why do these currently persist past downtime?
Salgare
Violence is the Answer
Wormhole Society
#6 - 2016-07-09 10:58:37 UTC
Well, deleting the app in the third party tool indeed kills any existing OAuth session.

If one then immediately re-authenticates ... It's like Poltergeist "their baaaack".

I'll log a bug on this one, as per current intended usage , applications should only be listed that have an active OAuth session.
nezroy
Nice Clan
#7 - 2016-07-09 15:58:08 UTC
Salgare wrote:

Yes, I assume the application still has access to your location, until the OAuth access_token times out (currently 20 minutes I believe). Hmmm, I suppose an ill-behaved OAuth implementation could continue to use the refresh_token regardless of if the user logged out.


No, the application has access to your location indefinitely. It can continue to use the refresh_token as long as it wants or until you revoke that access from the 3rd party apps page. This is an intentional part of CREST and is not a bug.

I agree that the way they went about merging SSO and application API access tokens for CREST into the same thing is a bit odd, but regardless it's behaving as expected.
Salgare
Violence is the Answer
Wormhole Society
#8 - 2016-07-09 17:43:10 UTC
nezroy wrote:
Salgare wrote:

Yes, I assume the application still has access to your location, until the OAuth access_token times out (currently 20 minutes I believe). Hmmm, I suppose an ill-behaved OAuth implementation could continue to use the refresh_token regardless of if the user logged out.


No, the application has access to your location indefinitely. It can continue to use the refresh_token as long as it wants or until you revoke that access from the 3rd party apps page. This is an intentional part of CREST and is not a bug.

I agree that the way they went about merging SSO and application API access tokens for CREST into the same thing is a bit odd, but regardless it's behaving as expected.


I assume they allowed for indefinite refresh because they knew, in their case, this would only ever be a max of 24 hours because of daily scheduled downtime. However that is beside the point as to if this should be considered a bug. For this feature to be of real use would be to indicate to the user that there is currently an active OAuth session from the indicated application, allowing them to kill it (basically an ill-behaved application that did not drop their refresh when you logged out).

What you currently have is a permanent history of every application that you have ever authenticated with, none of which could be active past the next downtime.

Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#9 - 2016-07-09 20:08:40 UTC
Actually, the goal with the refresh token would be to allow an application to continue to function for a user, without requiring them to reauthenticate on a regular basis.

It's very common behaviour, with this style of application.

An example:

Tweetdeck. I log into tweetdeck. It, the first time, forces me to auth with twitter and grant privileges. After that, I can switch off my browser, go away, come back the next day, and I'm still logged into it. That's using a refresh token to reauth.


What you see on that site is every application you've granted a refresh token to. So you can revoke those refresh tokens. They continue to work past downtime, as they should. Forcing users to reauth against TQ each day is a very poor user experience. Especially when it's for a non-interactive application. For example, I write a character tracker. I want to be able to track all my characters, across multiple accounts. I don't want to have to reauth each and every one of them. Ideally, I want to auth them once, and then have the backend tracker continually tracking them.

Or another example: Kill mails. you can grant access to your kills via crest. I don't want to have to relog into zkill every time I have a new kill, to get it to update. (yes, there's the old style api. But you can _also_ grant access to it via SSO, which is a _far_ nicer user experience, than forcing people to go create an api key)

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Salgare
Violence is the Answer
Wormhole Society
#10 - 2016-07-09 22:22:06 UTC
Steve Ronuken wrote:
Actually, the goal with the refresh token would be to allow an application to continue to function for a user, without requiring them to reauthenticate on a regular basis.

It's very common behaviour, with this style of application.

An example:

Tweetdeck. I log into tweetdeck. It, the first time, forces me to auth with twitter and grant privileges. After that, I can switch off my browser, go away, come back the next day, and I'm still logged into it. That's using a refresh token to reauth.


What you see on that site is every application you've granted a refresh token to. So you can revoke those refresh tokens. They continue to work past downtime, as they should. Forcing users to reauth against TQ each day is a very poor user experience. Especially when it's for a non-interactive application. For example, I write a character tracker. I want to be able to track all my characters, across multiple accounts. I don't want to have to reauth each and every one of them. Ideally, I want to auth them once, and then have the backend tracker continually tracking them.

Or another example: Kill mails. you can grant access to your kills via crest. I don't want to have to relog into zkill every time I have a new kill, to get it to update. (yes, there's the old style api. But you can _also_ grant access to it via SSO, which is a _far_ nicer user experience, than forcing people to go create an api key)


I see, yes it does make sense that some applications would not be "ill behaved" by not dropping auto refresh_token upon user logout.

I did make a bad assumption here, that downtime would drop all current OAuth sessions. I suppose this means that if I am a kill board type application, I need to retry refresh_token request failures for some reasonable amount of time (maybe forever??) to make it past downtime.

I was just scratching my head last night over what must be the same/similar issue at a different level. I have three subscriptions, and yet every time I run my application it comes up with an "authorize" or "cancel" button on the account I happened to first login to on my first SSO. In my development, I've not paid much attention and simply hit "authorize".

I assumed that if I hit "cancel" that it would have hit my OAuth callback with a failure. Trying this today left me scratching my head ... it solved the question of how I might switch over to another subscription, but I found behavior that I think is another bug. It logged out whatever was holding my last username/password/google authenticator subscription login on the server and presented with with a fresh login dialog where I could select another subscription. However it was then back to the "cancel" or "authorize" screen, with no way to indicate I don't want to authorize anyone, callback a failure and let everyone move on.

I can see I better put my own timeout starting when I first call https://login.eveonline.com/oauth/authorize and clearing on callback to mysite, and if it times out, overriding the redirect to the eve login dialogs back to some "anonymous" page.

Suggested bugs:

1. It seems the Eve authentication page should have three buttons; "cancel", "logout", "authorize", where cancel hits the callback with a user declined error.

2. I still maintain the support->3rd party is broken in that it still reports application/scopes that my application does not hold a valid access_token for, and is NOT calling refresh_token on.



Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#11 - 2016-07-10 02:36:31 UTC
Salgare wrote:
Steve Ronuken wrote:
Actually, the goal with the refresh token would be to allow an application to continue to function for a user, without requiring them to reauthenticate on a regular basis.

It's very common behaviour, with this style of application.

An example:

Tweetdeck. I log into tweetdeck. It, the first time, forces me to auth with twitter and grant privileges. After that, I can switch off my browser, go away, come back the next day, and I'm still logged into it. That's using a refresh token to reauth.


What you see on that site is every application you've granted a refresh token to. So you can revoke those refresh tokens. They continue to work past downtime, as they should. Forcing users to reauth against TQ each day is a very poor user experience. Especially when it's for a non-interactive application. For example, I write a character tracker. I want to be able to track all my characters, across multiple accounts. I don't want to have to reauth each and every one of them. Ideally, I want to auth them once, and then have the backend tracker continually tracking them.

Or another example: Kill mails. you can grant access to your kills via crest. I don't want to have to relog into zkill every time I have a new kill, to get it to update. (yes, there's the old style api. But you can _also_ grant access to it via SSO, which is a _far_ nicer user experience, than forcing people to go create an api key)


I see, yes it does make sense that some applications would not be "ill behaved" by not dropping auto refresh_token upon user logout.

I did make a bad assumption here, that downtime would drop all current OAuth sessions. I suppose this means that if I am a kill board type application, I need to retry refresh_token request failures for some reasonable amount of time (maybe forever??) to make it past downtime.

I was just scratching my head last night over what must be the same/similar issue at a different level. I have three subscriptions, and yet every time I run my application it comes up with an "authorize" or "cancel" button on the account I happened to first login to on my first SSO. In my development, I've not paid much attention and simply hit "authorize".

I assumed that if I hit "cancel" that it would have hit my OAuth callback with a failure. Trying this today left me scratching my head ... it solved the question of how I might switch over to another subscription, but I found behavior that I think is another bug. It logged out whatever was holding my last username/password/google authenticator subscription login on the server and presented with with a fresh login dialog where I could select another subscription. However it was then back to the "cancel" or "authorize" screen, with no way to indicate I don't want to authorize anyone, callback a failure and let everyone move on.

I can see I better put my own timeout starting when I first call https://login.eveonline.com/oauth/authorize and clearing on callback to mysite, and if it times out, overriding the redirect to the eve login dialogs back to some "anonymous" page.

Suggested bugs:

1. It seems the Eve authentication page should have three buttons; "cancel", "logout", "authorize", where cancel hits the callback with a user declined error.

2. I still maintain the support->3rd party is broken in that it still reports application/scopes that my application does not hold a valid access_token for, and is NOT calling refresh_token on.






Right now, cancel just logs you out of the eve sso, and doesn't return you to the application.

IIRC, there is no user declined option in oauth 2. I may be wrong. Been a while since I dug through the spec.

The 3rd party page contains a list of all the refresh tokens which exist. Because you should have the ability to kill any refresh token off. Doesn't matter if it hasn't been called. you should be able to kill it.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Salgare
Violence is the Answer
Wormhole Society
#12 - 2016-07-10 04:55:25 UTC  |  Edited by: Salgare
Steve Ronuken wrote:


Right now, cancel just logs you out of the eve sso, and doesn't return you to the application.


well kind of, it leaves you in an endless loop of EVE Authentication screen and EVE Login screen unless you accept. And yes, it leaves the user and the app in limbo. What's your choice ... close the tab and forget it (****, now where is my app page)?

Quote:

IIRC, there is no user declined option in oauth 2. I may be wrong. Been a while since I dug through the spec.

That would be crazy. This is not authoritative but a quick google search confirms: "The redirect to your application will include a code which you will need in the next step. If the user has denied access to your app, the redirect will include ?error=access_denied. " see https://developer.wordpress.com/docs/oauth2/

Quote:

The 3rd party page contains a list of all the refresh tokens which HAVE existED and may still exist. Because you should have the ability to kill any refresh token off. Doesn't matter if it hasn't been called. you should be able to kill it.


I fixed that statement for you. I agree with the need for the ability to cancel an active SSO and have verified that it does work. What I'm opposed to is having a history list of "HAVE existED".

Try this

1. MyApp SSO's for scopes s1, s2, s3 and Toon1 accepts
2. close down the application and wait for 21 minutes

3. MyApp SSO's for scopes s4, s5, s6 and Toon1 accepts
4. close down the application and wait for 21 minutes

At this point, if you have done the 21 minute waits there are no active/valid access or refresh tokens in the system associated with MyApp

Now Toon1 goes to support->3rdparty and see's MyApp listed twice with the scope sets they asked for. What are they to imply from this information?


eta:
OAuth knowledgeable Toon1 realizes something is bad because it should not be possible for two simultaneous MyApp SSO's to be active for different scope sets.

Paranoid Toon1 was told by the app developer that they would not maintain their SSO past their app logout, and yet, what the hell, MyApp developer must be a Goonsquad'er and is somehow screwing us. App developer: "Hey I promise, I drop it" Toon1: liar, right there .... CPP is telling me you are a liar, spread the word, it's right there in support->3rd parties!
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#13 - 2016-07-10 17:54:15 UTC
Salgare wrote:
Steve Ronuken wrote:


Right now, cancel just logs you out of the eve sso, and doesn't return you to the application.


well kind of, it leaves you in an endless loop of EVE Authentication screen and EVE Login screen unless you accept. And yes, it leaves the user and the app in limbo. What's your choice ... close the tab and forget it (****, now where is my app page)?

Quote:

IIRC, there is no user declined option in oauth 2. I may be wrong. Been a while since I dug through the spec.

That would be crazy. This is not authoritative but a quick google search confirms: "The redirect to your application will include a code which you will need in the next step. If the user has denied access to your app, the redirect will include ?error=access_denied. " see https://developer.wordpress.com/docs/oauth2/

Quote:

The 3rd party page contains a list of all the refresh tokens which HAVE existED and may still exist. Because you should have the ability to kill any refresh token off. Doesn't matter if it hasn't been called. you should be able to kill it.


I fixed that statement for you. I agree with the need for the ability to cancel an active SSO and have verified that it does work. What I'm opposed to is having a history list of "HAVE existED".

Try this

1. MyApp SSO's for scopes s1, s2, s3 and Toon1 accepts
2. close down the application and wait for 21 minutes

3. MyApp SSO's for scopes s4, s5, s6 and Toon1 accepts
4. close down the application and wait for 21 minutes

At this point, if you have done the 21 minute waits there are no active/valid access or refresh tokens in the system associated with MyApp

Now Toon1 goes to support->3rdparty and see's MyApp listed twice with the scope sets they asked for. What are they to imply from this information?


eta:
OAuth knowledgeable Toon1 realizes something is bad because it should not be possible for two simultaneous MyApp SSO's to be active for different scope sets.

Paranoid Toon1 was told by the app developer that they would not maintain their SSO past their app logout, and yet, what the hell, MyApp developer must be a Goonsquad'er and is somehow screwing us. App developer: "Hey I promise, I drop it" Toon1: liar, right there .... CPP is telling me you are a liar, spread the word, it's right there in support->3rd parties!



Ahh. There's where your mistake exists.

Refresh tokens don't time out. So after 21 minutes, the refresh token associated with MyApp is still active/valid.

That app can come back, at pretty much any time it feels like, and get an access token, using that refresh token.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Salgare
Violence is the Answer
Wormhole Society
#14 - 2016-07-10 18:10:10 UTC  |  Edited by: Salgare
dup
Salgare
Violence is the Answer
Wormhole Society
#15 - 2016-07-10 18:37:54 UTC  |  Edited by: Salgare
Steve Ronuken wrote:

Ahh. There's where your mistake exists.

Refresh tokens don't time out. So after 21 minutes, the refresh token associated with MyApp is still active/valid.

That app can come back, at pretty much any time it feels like, and get an access token, using that refresh token.



Oh interesting, so in theory I could push the refresh token to my db and it's life would exceed my applications life. I had it in my head if you did not keep refreshing before the 20 minutes you "dropped the ball" and the refresh_token would not be valid anymore.

Another mistake I made was assuming the Auth server was the Crest server. I started an aggressive 1 minute refresh access_grant right before down time this morning and it keep on sailing, never hitting the retry on error code I was expecting.

My head's been into old school login/out for security reasons. Time to get with the new kids and understand Single Sign On, indeed means Single. In other words, not only in theory should I persist the refresh token in my db, I should do it in practice for my users convenience. Right?


I wonder how far I go, using browser cookies to help me find my persisted refresh_token for a given user so they don't have to authenticate to application privileged pages on my site? I suppose two button clicks is plenty convenient verses having to enter user/pass each time .... nan I'll draw the line here for access rights to the applications pages.


Steve, thanks for sticking with me on this!
Steve Ronuken
Fuzzwork Enterprises
Vote Steve Ronuken for CSM
#16 - 2016-07-10 19:17:35 UTC
Salgare wrote:
Steve Ronuken wrote:

Ahh. There's where your mistake exists.

Refresh tokens don't time out. So after 21 minutes, the refresh token associated with MyApp is still active/valid.

That app can come back, at pretty much any time it feels like, and get an access token, using that refresh token.



Oh interesting, so in theory I could push the refresh token to my db and it's life would exceed my applications life. I had it in my head if you did not keep refreshing before the 20 minutes you "dropped the ball" and the refresh_token would not be valid anymore.

Another mistake I made was assuming the Auth server was the Crest server. I started an aggressive 1 minute refresh access_grant right before down time this morning and it keep on sailing, never hitting the retry on error code I was expecting.

My head's been into old school login/out for security reasons. Time to get with the new kids and understand Single Sign On, indeed means Single. In other words, not only in theory should I persist the refresh token in my db, I should do it in practice for my users convenience. Right?


I wonder how far I go, using browser cookies to help me find my persisted refresh_token for a given user so they don't have to authenticate to application privileged pages on my site? I suppose two button clicks is plenty convenient verses having to enter user/pass each time .... nan I'll draw the line here for access rights to the applications pages.


Steve, thanks for sticking with me on this!



Persisting the users refresh token only makes sense if you need to use it, while they're not using your site. There are plenty of cases where this is needed, and plenty where it's not.

If you persist the users authentication, so they don't have to sign into your site every time they visit in a new browser session, it makes sense to persist the refresh token.

Woo! CSM XI!

Fuzzwork Enterprises

Twitter: @fuzzysteve on Twitter

Dragonaire
Here there be Dragons
#17 - 2016-07-10 20:17:17 UTC
Salgare - the best way to look at SSO is you are authorizing the site to act as an agent on your behalf and it doesn't matter if ur both on speaking terms or not. You fire them by letting the SSO provider know and they take care of letting everyone else know as well when they ask including the agent.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.