I see the ESI is using OAuth2 for authorization of the API. Since this uses a browser for SSO (as per best practices of OAuth2) and relies on form posting and redirects to obtain authorization tokens.
How can one authorize a client that has 1) no browser and 2) no UI with OAuth2 authorization flow?
Using a browser and UI is a no go for a service and command line app flow.
Can we obtain a long lived (and revokable) token with or without OAuth2 for such a headless scenario, or API key, and, will CCP be adopting IETF GNAP [1] that addresses such use cases?
You can’t. Current implementation requires them. At least for the first flow. Once you have the refresh token, the user won’t need the browser again for the most part. So your CLI flow or whatever could be used just fine. The refresh token would last for a month if unused, or until the user revokes the grant/changed their password.
Then your best bet would be to do the auth on another computer with a browser and copy the credentials to it. Such as to a database, file on disk, etc.
Also to be clear the server itself doesn’t need to have a browser or anything. That could be setup to handle the flow, but you could initiate the flow from another computer that does. As all the server needs to do is some HTTP requests, with a small lightweight web server to handle the routing and logic of what to do for each step.
In short: Create the refresh_token(s) on a computer with a browser and move the refresh_token(s) to your headless device. Expect nothing new (like this or anything else) to be added to ESI anytime soon…
Again to be clear, the server itself can be headless and does not require a GUI or desktop environment as long as it is setup to handle the OAuth flow, which could be initiated from a computer that does. I.e. the one you’re using to reply to this thread.
If you do not want to server to have a webserver at all, then you would have to do the flow manually on your computer, via Postman or something, and copy the credentials over manually. However the server will need something to handle the refreshing of the token.
I was thinking more of an app that you put in the client ID and the private key and pull out and store refresh and access tokens then put them to the headless apps. Just a simple provisioning app for any clients and keys, that provisioning app will be user facing for authorizing when need be.
You can initiate the OAuth flow from any computer that has a browser, which does NOT have to be on the same computer as the server. I’d checkout SSO Authorization Flow | esi-docs if you haven’t already as it walks thru the flow.
The gist of it is you do a GET request to a URL that includes a redirect URL, which would be your headless server. Once you login, it redirects to that URL, you exchange code for a token, save it, and redirect the other somewhere else if you want. There is no need for the headless server to have a browser or anything at all.
Sure, I would rather break that out to a general provisioning app then copy that across to the headless app. One to manually manage authorization and obtaining valid tokens, and the headless app to do what it does and less bloating with simulating human sign on stuff it won’t need.
I simply hate OAuth2. A failure of design by committee and doesn’t work well with modern needs and is stuck in the year 2010’s.
Still don’t see the reason to maintain two apps…but okay. The headless app doesn’t need to simulate anything as its just responding to HTTP requests, no human interaction required…
Right, but you’re not doing that signon from the headless app/server itself. You can do it on any browser, as long as that computer has access to the headless app/server. E.g. public over internet, or localhost so the OAuth flow can process the OAuth redirect.
I feel like technically the refresh_token works pretty much like the legacy XmlAPI id/keys.
Making a callback page that give you the authorization code or refresh token, is super simple.
IMHO SSO only adds functionality, it may make things marginal harder, but, with the amount of ready to use libraries, it should be trivial.