EVE Technology Lab

Your application should always throw the user out to their web browser to go through the authentication steps, and then have them redirected back to your application in some fashion.

Two common ways to do it:
Embed a webserver to handle the redirect. (so you redirect to something like http://localhost:3423/login, and that gets the details needed to finish the auth)

Have a helper application which you register as a handler for a custom url scheme. like steveisawesome://localhost/login. That communicates with your regular application, probably with socket code, to hand over the auth details. you use the custom url scheme as the redirect uri on the developers site.

You use the client id and secret to identify who your application is to the SSO. The user still uses their regular details with it.


If you're only using the application yourself, you can cheat a bit, and use a pregenerated refresh token. You just wouldn't want to distribute that.

For OAUTH2, you don't want to use the postman which embeds into chrome, but the packaged app version you can get from https://www.getpostman.com/

There's a full oauth2 client, which tells you how to set it up. (you have to set the redirect_uri properly with it)

If you can read PHP, https://github.com/fuzzysteve/CrestLibrary may be of interest.


I generated a refresh token, and stuck it into the configuration file (for the example code)

Now, when my application needs to talk to CREST, it uses that refresh token to create an access token. That access token is for my account, with the appropriate privileges. No username/password required at that point.

I/My application can then use CREST, authenticated as me, getting new tokens, as the old tokens come up for expiry.

Does that make sense?

Embedding the web engine leads to very poor practices though.

You should never have your application request (directly) a users Eve username and password. Ever. At all. Yes, it may be in an embedded web browser, and you don't actually see it. Still, it's incredibly bad practice for user education.

The second method isn't so bad. You could even extend it, so that it sends the client to your site, with a unique identifier, where they then go through the normal auth method (hit your site, create a session there, auto redirected to auth where they auth and it comes back, filling in the details in that session) and your app just polls every so often for that unique identifier, till it times out, or they're authed.