I’m working on a personal project, in PHP using MySQL, just working on basic character auth, and I’m trying to figure out what I should store and where I should be storing it. I have a php class written to perform the auth and obtain an access token and refresh token, I’m just not sure what to do with those tokens when it comes to the user going to a different page. Should I save those tokens in the session variables? or save them in the database? I’m going for security, and I’m just not sure which token I should be saving and what’s the most efficient.
An access token expires in about 20 minutes. A refresh token lasts indefinitely, or until the user revokes your app’s access.
Store the refresh token where you need it for generating new access tokens.
Store access tokens where you need them for pulling ESI data.
I would prefer not to expose either of these two values to the client, and would save or cache them server side. If you want your application to stay authenticated, you will need to at least store the refresh token in a permanent fashion, or the user will have to log in again to generate another one for you. Access tokens are less important because if you don’t have one you can just use the refresh token you have saved to get another access token on demand.
My understanding of these things is limited so I would seek out corroborating evidence or a more experience person’s answer, but in the event you don’t get a better answer, I thought I would do my best to give you the best answer I could manage with what little I know of ESI and web based application programming.
I found some documentation here, in the off chance you have not found it already:
https://test-eveonline-third-party-documentation.readthedocs.io/en/latest/sso/index.html
Alright, good stuff, thanks, what I need to know now is how I would go about caching the access token in a way that’s able to be accessed from other php pages, if anything, I’d save the refresh token in a relation, as well as the access token, when a request is made and the token’s expired, use the saved refresh token and update the saved access token, just not sure if there’s much of a way to pass the active token over through post requests, or if session variables are stored client side
https://www.w3schools.com/php/php_sessions.asp says that the sessions are not stored client side.
What you store where is pretty much a matter of taste. If you want to be able to pull information, the bare minimum is characterID and refreshToken. In addition you might wanna store the accessToken. If you use SSOv1 you should store the expiry if you store the accessToken, when using SSOv2 things such as expiry and scopes are includes in the accessToken, so you wouldn’t have to store the separately but it still makes a lot of stuff easier.
So what I do is using one table that contains characterID, name, ownerHash and whatever information I use to log the user in (email, password whatever) and another one that contains characterID, scope, accessToken and refreshToken.
For stuff that needs to be carried over (characterID and Name) i use $_SESSION, which is not stored client side.
Is SSO not suitable for website authentication?
Say I wanted them to just login to my site with their Eve online account.
Is this appropriate or should I just be having them sign up with my own user authentication and then add characters some how?
SSO is perfectly fine as auth mechanism. You should make sure to recognize people by their owner hash, as this would change if a char was sold.
All the above was about logins using scopes. Best practice would be to have a primary auth mechanism which may be SSO or anything else and only request scopes when needed. Tbh all my apps will already request minimal scopes upon login (which uses SSO as primary auth) because they do nothing without scopes.
Currently I’m getting an invalid state error from esi when trying to log in again.
What’s the correct method to get login.eveonline.com so return an owner hash upon successful credential entry?
I’m having trouble getting it to tell my callback who logged in.
So I’ve fixed my error. I think I was just sending incorrectly formatted json. I tried the alternative of just sending post data and it worked.
Interestingly, the server only replies with your one time use code. In order to grant access to your application you need to immediately fetch the refresh token and the access token.
The refresh token and access token are different on each fetch. So these are unsuitable for matching to a user in your database.
I assume the refresh token can be used to gain a new access token after the access tokens 20 minute lifespan.
This seems unusual to me. Why not just give me one token to use at the endpoints? Why give me one token I can always use to gain another token that’s going to die in 20 minutes?
The same thing can be achieved by just giving me an access token that doesn’t die for use at the endpoints.
Any how, finally you can use this info to fetch an owner hash that will remain consistent as long as the same Eve account owns the logged in character.
You can match this up in your database and log them in!
Finally I’ll eventually add a feature where they can add alts into the system. If they ever log in on an alt character there will be a connection in the relational database that logs them in under their main.
Sadly, if they log in as an alt without having previously added it as an alt, it will register that alt as a new account and and reset the applications state for a new user.
ESI does not provide a way to decipher what account a character belongs too.
That’s how OAuth works. https://docs.esi.evetech.net/docs/sso/sso_authorization_flow.html. It’s mainly for security reasons.
Also btw, proper SSO requests use application/x-www-form-urlencoded content type versus JSON.
That’s good since that’s what I ended up using.
I just don’t get the two token thing. They’re giving me indefinite access any way.
It’s like having a key that opens a box that drops a key that opens a door.
I still only need the one key to open the door. Why not just do away with the stupid box? And make my one key work on the door?
This is more of an OAuth question. I’d suggest googling like Why does OAuth2 use refresh_tokens or something along those lines.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.