upon programming with ESI, i asked myself, how to get accesstokens for 1 char with the same sso of an app on different PCs.
My SSO Auth works fine an i can obtain the accesstokens and refreshtokens just fine. But what will happen, if i log in with sso on PC 1 and obtain my tokens and then log in with the same app on PC 2 with the same appID and secret key to obtain access and refresh token on PC 2? Are the Tokens on PC 1 still valid and i have 2 pairs of tokens then? One pair for PC 1 and one pair for PC 2 or does ESI only allow one pair of tokens for each character and app?
I haven’t fully tested it yet, but it doesn’t look like it is tracking IP addresses. You can have multiple different users sitting behind one, masquerading firewall with a single IP address, or, you can have the same user (same alt, different alt - doesn’t matter) accessing ESI with different streams of cryptographic tokens.
What seems to matter is that you don’t break the stream of tokens and you’ll be fine.
You do have to go through the SSO process each time though and create a new stream of tokens and cannot somehow fork off new streams from an existing stream.
i dont think it has to do something with IP adresses. The 2, 3, 4, 5 or some PC could be in different locations. For exsample, a corp member gives you the Access Code generated from an SSO invite Link for this programm. Now the corp leader wants to check the the Account Status via this Acces Code. So he uses it to get an Access Token and a Refresh Token. But what will happen, if the member not generates a new Access Code and retrieves a Acces Toke and refresh Token, is the first one still valid?
Only by this stream is a user being identified. So you have to make sure that whenever an app wants to access the user’s data you own a coherent stream, or it will fail.
This means for your corp member to hand over a stream to the corp leader. How and when doesn’t matter. What matters is that this stream stays coherent.
Yes, you can, but you do need to go through the SSO process each time and start a new stream.
And no, ClientID + Secret + Character alone aren’t enough to create an identification. You have to get an initial one-time code, too, and start a new stream.
I hope you realize that with what you’re trying to do you’re basically trying to copy identifications, and that’s just really a bad thing to do when the whole point of it is to uniquely identify someone and not have your identity stolen for instance. It’s important for the whole process that an authorization / identification cannot simply be copied around and multiply uncontrollably. It has to be established for everyone and everything that wishes to access a character’s protected data.
I know the process of getting a accesstoken stream and what to do. With what you described there is no way, with the current ESI-system, to grant someone a permanent and secure way to share your data. If i do a new SSO and generate a new Access Code, any former token stream gets invalid and is closed.
Blockquote
I hope you realize that with what you’re trying to do you’re basically trying to copy identifications, and that’s just really a bad thing to do when the whole point of it is to uniquely identify someone and not have your identity stolen for instance.
Thats because, a this moment, there is no way to identify 2 diffenrent users of the client how want to access the same data. There is no way to allow someone else the permanent right (or till you revoke it) to view your information.
Maybe it could be done with an invite link. You generate a guest Token and the guest has to log in with his own sso. Then you could grant or revoke all guest tokens in your own API management page.
With server side apps the current system works because they can handle the view/read/write whats else permissions on the dedicated web server. With standalone PC programms there is now no way to share information between different users. Maybe there is a way which i dont know.
I have given you an answer more than once. I suggest you start reading before you post any further questions. Comprehending what has been told to you is essential for this conversation to continue.
I am doing something similar to this since I use microservices. You can have multiple access_tokens in flight at once from the same refresh_token from different locations.
I have a central service hold the token pair and other services request either access_tokens or token pairs from there.
However if you are doing this for a desktop app so you can keep your secret hidden, you will also be responsible to ensure that your token service is not exploitable and will be accountable if it is abused.
CCP is working on a JWT solution for desktop apps.
Are you certain? I know I can have multiple streams, but I could not reuse an old refresh token. Once a refresh token is being used to get a new access token and refresh token is the old refresh token of no further use.
However, I don’t seem to be able to test anything at the moment due to these DDoS attacks. Half the time it won’t even give me the Account/Password window today.
The refresh token never changes.
I am pulling info for about 90 characters at the moment and all I store is the refresh token.
So far (other than the ESI timing out or returning undocumented codes) it’s worked every time.
I’ll try again once these DDoS attacks stop. If one can indeed fork off streams from an existing stream then that’s bad for security, because then all it needs is to steal one, single refresh token and anyone can have indefinite access until a user notices it and revokes it at CCP’s web site.
What I’m having problems believing right now is the statement of a refresh token never changing. I know that two SSO sessions (for the same character), lead to two different refresh tokens. And I know that one always gets an access token and a refresh token returned with a refresh request. But how can you be sure the refresh token never changes?
Is this an assumption or is this a documented feature? I know I could be given a new refresh token at any time I’m requesting a refresh and thus I haven’t made the assumption and considered it bad programming, although it does appear not to change for at least some time.
The way I’m doing it for now is to copy the newly returned refresh token over the old one. If it changes, or not, is of no concern to me. Instead, do I assume I will always get a valid refresh token with each refresh request. Should the authentication server then decide to update the refresh token (due to some internal mechanism of its own and one that I don’t know about) do I not need to worry about it, but will automatically be working with a valid refresh token. While I’m aware that it is also only an assumption that I’m making do I believe it is a saver assumption than to assume to always be given the same refresh token and to only hold on to the very first one and to ignore all others.
I’ve had the chance to test it some more today and not only is it possible to use an older refresh token, because these don’t change for at least some time, but it is also possible to produce several unique access tokens from a single refresh token without invalidating these access tokens.
This worries me a bit, because it means one really only needs a client’s id, secret and a single refresh token to access somebodies stuff, and they won’t even notice it, because it’s not going to invalidate anyone’s tokens. Getting a client’s id and secret should then not be too much of a problem for downloadable tools and passing around a refresh token becomes as easy as passing around somebodies password…
Which is why you don’t give out the secret. For desktop apps, the user should register for their own app and use that secret and clientID. As already stated, CCP is working on a solution for these cases since you have to have paid them at some point to register an app.
