Hmmm seems you were right… I did some tests, and the token authentication seems to be independent from the session management.
To logout, you have to POST to SessionMod/Logout including a header SessionInfo, containing the GUID you get from Login, like this: SessionInfo: {“SessionID”: 232a2868-cf60-46f1-8dba-1ac53328a66b}. This effectively closes the Epicor session.
However, that doesn’t invalidate the token! Seems the authentication token is still valid for its entire lifetime no matter what. In fact you can call Login again with the same token to reopen a new session. There doesn’t seem to be any way to invalidate the token.
So, the order of things is:
1- Call TokenResource.svc, get a new token
2- Call SessionMod/Login with your token, get a session ID
3- Include the SessionInfo: {“SessionID”: 232a2868-cf60-46f1-8dba-1ac53328a66b} header and the Authorization: Bearer TOKEN header for every subsequent request. (and API key for V2!)
4- When you are done, call SessionMod/Logout, still including both headers. This closes the Epicor session, but the token is still valid and you can reuse it to open a new session. You cannot however keep using the same SessionInfo header, services will return 400 something.
5- If you only include the token without the SessionInfo header, a new session is created with each request, same as if you were using basic authentication.
So, the solution is just to “forget” the token and let it expire once you’ve logged out, and to log back in with a new token and a new session if you get a 400.
I would really have expected the auth token to expire with the session though…