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.
 

Oauth 2 for installed applications
Author
Previous Topic Next Topic
Tristan Ekain
The Scope
Gallente Federation
#1 - 2015-03-24 10:11:42 UTC
I'm about to write a locally installed application that uses the authenticated CREST API. While researching how to best handle authentication (which isn't exactly 'comfortable' for non-web applications), I found this document from Google:
https://developers.google.com/accounts/docs/OAuth2InstalledApp

Google supports three special values for the redirect URL field, which make live much easier for an application developer. You can find them in section "Choosing a redirect URI". Is this something that could be considered for CREST authentication?

Also, if I set "localhost" as redirect URL when I register an application, will the authentication server verify the port, too? Or can I just pick any port (which is basically essential for a local application, as there's no guarantee that any fixed port is free)?
Pete Butcher
The Scope
Gallente Federation
#2 - 2015-03-24 10:31:38 UTC
That's actually a quite complex topic. Using localhost may not work everywhere because of system security and/or other applications hijacking your port. In Evernus I chose 2 methods - complete internal authentication using internal Web engine, and external authentication redirecting users to a page with a code which they copy-paste into the application. When you distribute your app, you'll notice how many problems oauth involves and how many edge cases do happen.

http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool
Tristan Ekain
The Scope
Gallente Federation
#3 - 2015-03-24 11:00:55 UTC
Pete Butcher wrote:
That's actually a quite complex topic. Using localhost may not work everywhere because of system security and/or other applications hijacking your port. In Evernus I chose 2 methods - complete internal authentication using internal Web engine, and external authentication redirecting users to a page with a code which they copy-paste into the application. When you distribute your app, you'll notice how many problems oauth involves and how many edge cases do happen.


Yeah, OAUTH is an ugly beast for desktop applications; seems like those were just an afterthought, with the focus being web applications.

I'm not going to make it work in 100% of the edge cases. That's just too much work for a hobby. So if for example some firewall blocks localhost -> localhost traffic, I don't care. That sounds like something that would only happen on corporate PCs.

The port already being in use is the more interesting case. That's why I asked whether the CREST auth server checks the port too, or only the hostname.
Google, as described in that document I linked, seems to have a special verification mode when the callback URL is "localhost". In this case, they don't check the port number, so an application can just request a random port from the operating system and use that.

The other modes Google supports are also interesting. They basically result in the auth server displaying a special page with the token, which the user can then copy and paste into the application. That way, the application developer does not have to create a special webapp just for that.

Let's see if maybe CCP FoxFour can say something about. that. This is a topic that comes up quite often, and with something like what Google's doing in their OAUTH servers, live can be made much easier for app developers.
Pete Butcher
The Scope
Gallente Federation
#4 - 2015-03-24 11:27:43 UTC
Tristan Ekain wrote:
Pete Butcher wrote:
That's actually a quite complex topic. Using localhost may not work everywhere because of system security and/or other applications hijacking your port. In Evernus I chose 2 methods - complete internal authentication using internal Web engine, and external authentication redirecting users to a page with a code which they copy-paste into the application. When you distribute your app, you'll notice how many problems oauth involves and how many edge cases do happen.


Yeah, OAUTH is an ugly beast for desktop applications; seems like those were just an afterthought, with the focus being web applications.

I'm not going to make it work in 100% of the edge cases. That's just too much work for a hobby. So if for example some firewall blocks localhost -> localhost traffic, I don't care. That sounds like something that would only happen on corporate PCs.

The port already being in use is the more interesting case. That's why I asked whether the CREST auth server checks the port too, or only the hostname.
Google, as described in that document I linked, seems to have a special verification mode when the callback URL is "localhost". In this case, they don't check the port number, so an application can just request a random port from the operating system and use that.

The other modes Google supports are also interesting. They basically result in the auth server displaying a special page with the token, which the user can then copy and paste into the application. That way, the application developer does not have to create a special webapp just for that.

Let's see if maybe CCP FoxFour can say something about. that. This is a topic that comes up quite often, and with something like what Google's doing in their OAUTH servers, live can be made much easier for app developers.


That second method is the same as the external one in my case. It has the benefit of relying on a simple copying and pasting, which pretty much always works. A mix of internal and external solutions seems to work for everyone. Localhost is problematic and if your software gets popular, you'll eventually get bug reports.

http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool
Tristan Ekain
The Scope
Gallente Federation
#5 - 2015-03-24 11:31:44 UTC
Pete Butcher wrote:

That second method is the same as the external one in my case. It has the benefit of relying on a simple copying and pasting, which pretty much always works.


There's one difference: AFAIK you have your own website which displays the token. In Google's approach, the auth server takes care of that, so the app developer doesn't have to set up a web site just for this.
Pete Butcher
The Scope
Gallente Federation
#6 - 2015-03-24 11:51:22 UTC
Tristan Ekain wrote:
Pete Butcher wrote:

That second method is the same as the external one in my case. It has the benefit of relying on a simple copying and pasting, which pretty much always works.


There's one difference: AFAIK you have your own website which displays the token. In Google's approach, the auth server takes care of that, so the app developer doesn't have to set up a web site just for this.


Eve SSO doesn't offer that, so we have to do things manually. Maybe someday ccp will give us that option.

http://evernus.com - the ultimate multiplatform EVE trade tool + nullsec Alliance Market tool