Hi I am getting this token expired message. What are they about? I have version 1.17 setup on CentOS Stream 8. I have to re-enter the login info and it went away. Is that always manual process?
Thanks
token expired with OAuth2
- Edited
Hi Kevin,
My appologies, I thought I have attached the screenshot. Here is the screenshot.
User reported they didn't get any new tickets for a while. Then I found that token was expired and didn't refresh. Clicking "Submit" refresh and worked again. Not sure why it didn't refresh.
Is it a Microsoft email? If so this means changes were made on the MS side that invalidated the tokens.
Cheers.
In that screen shot:
You should be able to click Submit.
Then re-enter the M365 username/password, and authorize and the token should renew.
We've just had this occur, but only noticed it 8 days after it occured when our guys mentioned tickets were quiet - expired 31 Jan!!
Question is, what could've caused it? I'm not aware of changes on Azure, nor for the OSTicket specific accounts. Azure's App Reg tokens were still good till late 2024.
Not only that, this was not alerted on either 'email diagnostic' tests or the DEBUG level logs within OST. Surely one of those should've come up with the oauth failure and not make out it's happy when it's clearly failing/being denied?
Is this going to be a re-occuring issue or did MS do something that could've affected things?
Also, the main reason i post: why is OST Oauth2 > config > Token showing a 90 minute lifetime, when our App Reg Token is 2years? The two seem to be unrelated, but since the OST side Token was the one that that expired... whats the reason/way to be alerted on this in the future?
what could've caused it? I'm not aware of changes on Azure, nor for the OSTicket specific accounts.
Bug in the plugin where we don't update the refresh token. Only MS (of course) provides a new refresh token and we didn't know that. Typical OAuth2 conventions you only get a new Access Token but hey, MS loves being different. The next build of the plugin will include the fix.
Surely one of those should've come up with the oauth failure and not make out it's happy when it's clearly failing/being denied?
We are working on better logging for such cases.
why is OST Oauth2 > config > Token showing a 90 minute lifetime, when our App Reg Token is 2years?
Because these are completely unrelated. The Access Tokens expire typically every hour and then you use the Refresh Token to refresh and get a new Access Token (and in MS case a new Refresh Token as well). The Client Secret expires in 2 years so at that point you'll have to go generate a new secret, update the email config(s), and re-authorize the email(s).
Cheers.
thanks for the info on those things. We did update from 1.7.0, to 1.7.2 too so when 1.7.3 is out, i'll get that applied ASAP. untill then, i'll get the helpdesk to frequently monitor the mailbox and hope this doesnt happen again till the bugs are ironed out.
Im glad someone else is having the same issue i am, i'm having to manually refresh the token every hour or so as osTicket doesn't seem to be doing it automatically
So just to make sure, this is a known issue? or is what i've explained unrelated and i've missed something?
Is there any ideas on a timeframe for a fix or a potential workaround?
Thanks in advance
You should have a cron job running so it will automatically renew the token for you.
Cheers.
+1 Happened a couple weeks ago. Happened on an osticket this week again. It's easy enough to save again and enter the account and password, but I don't see a pattern for what causes it. A couple weeks ago it was each osticket I have set up. This week it was only one but the others were fine.
There is a current bug with the plugin where we are not updating the refresh token. The fix will be included in the next release and builds of plugins. Stay tuned.
Cheers.
osticketnoob22 Auto fetching is enabled. I'm on Windows. IIS but there's a scheduled task that is running. There's an issue with one osticket set up where that's not happening but that osticket did not have an expired access token this week.
Agents are logged into osticket too. On osticket set ups where no one's logged in, this week those still have green access tokens, so it doesn't seem to be related to being logged in or not.
I was wondering if it was something on the email account side but I don't see the pattern, especially for one of my ostickets expiring earlier this week while the rest are green.
At least you don't have to remove and readd the whole account. Resaving it after clicking into the access token page seems to fix it but apparently that doesn't last forever.
Thanks. Why is starting in late January and February 2023 and not more like last November? Or, did Microsoft change something that doesn't quite work now? I'm still on v17.1.
I will say that you should upgrade to v1.17.2 and install the latest version of the OAuth2 plugin.
Cheers.
osticketnoob22
Microsoft have hard shutdown older protocols starting in January, some tenant protocol was still being used in the backend
You can check if your tenant device(s) is still trying to use:
https://howtohelpdesk.com/how-to-get-basic-authentication-azure-ad-sign-in-log/
For "next release and builds of plugins" is that something like a v17.3 osticket update or just a plugin revision? Or, "yes," both, a new osticket update along with a new plugin for this issue?
KevinTheJedi I'm facing same issue with Google Cloud. Is it also because of the bug in the plugin?