Could the module be modified to account for the server timezone being different from GMT?
We've started using this component in our on-prem OutSystems servers. For any application using this, it seems to work great for a while - the application requests an access token from the service and receives one. It can then use this token to access other resources defined in Azure AD.
After a while, we are seeing that our applications will request a token and receive an expired one. They then try accessing resources with the token and receive an error due to the token being expired.
Doing more investigation, it seems that the service does have logic to exchange its refresh token for a new access token when the existing token has expired -- preventing an expired one from being returned. However, the way that it checks whether the token is expired seems be failing. Looking further, it seems that when it saves off the expiry time for the TokenRequest, it uses this expression, which seems to interpret the timestamp as local time, rather than GMT (which is what Azure AD is returning):
AddSeconds(NewDateTime(1970,1,1,0,0,0),TextToInteger(RefreshToken.Response.Expires_on))
Consequently, we end up with a time that is (in our case) 6 hours past the actual expiration time of the token, and the logic does not trigger a refresh (instead returning the stale/expired token).
As a workaround, we're planning to add logic that wraps this component/service, which will force refresh of the token if it is actually expired. However, it seems much more ideal for the TokenRequest record to store the correct local/server expiration time in the first place, as it may fix scenarios we are not considering, and keeps things simpler.
This can happen when your server timezone is not in UTC. Since there is no check on the server timezone in the logic and microsoft token expirations always come back in UTC, this is where you are probably getting your issue.
@Miguel Amado is there any way we can change the source code to check server timezone and make the appropriate conversions if necessary? I ask you because it's generally bad practice to just change Forge component source code as you end up falling off the upgrade path for the component. If possible you could add me to the component team and I could make the change. I can't imagine George is the only person to ever have this problem.
Hi,
I am facing the similar kind of issue. I have posted the same in below thread,https://www.outsystems.com/forums/discussion/101352/microsoft-login-connector-traditional-web-single-sign-on-using-microsoft-logi/
If anyone work around it please post the solution on my thread.Thanks.
Hi everyone,
Is there any solution for this issue?
Thanks
So, I am technically a member of this component team therefore don't take this as me promoting my own component over this one. However, I ran into a bunch of problems like this a few years back that all stemmed from the fact that this component uses the v1 endpoints for token retrieval. I also had some other ideas for improvement so instead of introducing a mountain of breaking changes to this component, I released the Azure AD Login Connector component which is basically a fork of this component with several changes including using the v2 APIs. The reason this is pertinent for this thread is that in the v2 token payload, you get an "expires_in" value which is just a number of seconds so you can calculate your own expiration datetime.
Take a look and consider updating. I don't know Microsoft's timelines for the v1 endpoints, but I do know that the v2 endpoints have several improvements that are worth the time to upgrade for. Find it here:
Azure AD Login Connector - Overview (O11) | OutSystems