Mobile App OpenID Redirect URI Incompatible with Azure AD

Hello Traccar Team,

I’m integrating the Traccar Manager mobile app with Microsoft Azure AD using OpenID Connect, and I’ve run into a redirect URI compatibility issue that appears to come from the mobile app’s implementation.

During authentication, the Traccar Manager app sends the following redirect URI:

org.traccar.manager:/api/session/openid/callback
Notice that it contains only one slash after the scheme (org.traccar.manager:/).

Azure AD requires an exact string match for redirect URIs, but it also enforces a stricter validation rule for custom schemes: they must follow the format:

customscheme://path
Because of this, Azure AD rejects the single‑slash URI. It cannot be added through the Azure Portal, Azure CLI, or Microsoft Graph API. All attempts return a validation error, even though the URI is technically valid per RFC 3986.

To confirm, Azure AD does accept this version:

org.traccar.manager://api/session/openid/callback
…but the mobile app does not use it.

As a result, authentication fails with:

AADSTS50011: The redirect URI does not match the registered redirect URI.
Would it be possible to update the Traccar Manager mobile app so that it uses the standard custom‑scheme format with two slashes after the scheme, for example:

org.traccar.manager://api/session/openid/callback
This change would make the redirect URI compatible with Azure AD and allow the OpenID login flow to complete successfully.

Thank you for your help, and please let me know if you need any additional details.

Let's try this:

https://github.com/traccar/traccar-manager/commit/27aa31f6215a91ec4876df3ee957b59016ab4ac9

If I'm reading the code change correctly, it looks to be a smart solution that would allow both URI formats to be consumed correctly.

What is the typical timeframe from a merge into main to make it into a published app in the app store?

Thanks for the quick turnaround!

There's no regular schedule.

I see that Traccar Manager was updated to version 6.0.0. The behavior of the Microsoft Entra OIDC login experience has changed. Now it is redirecting to EntraID and successfully redirecting back to the mobile app, but fails with:

java.security.GeneralSecurityException: Unable to authenticate with the OpenID Connect provider
      at org.traccar.database.OpenIdProvider.getToken(OpenIdProvider.java:131)
      at org.traccar.database.OpenIdProvider.handleCallback(OpenIdProvider.java:170)
      at org.traccar.api.resource.SessionResource.requestToken(SessionResource.java:185)
      at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
      at java.base/java.lang.reflect.Method.invoke(Method.java:580)
      at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java:52)
      at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:146)
      at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:189)
      at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:176)
      at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:93)
      at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:470)
      at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:394)
      at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:80)
      at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:274)
      at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)
      at org.glassfish.jersey.internal.Errors$1.call(Errors.java:244)
      at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
      at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
      at org.glassfish.jersey.internal.Errors.process(Errors.java:244)
      at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:266)
      at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:253)
      at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:703)
      at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:422)
      at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:374)
      at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:355)
      at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:309)
      at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:202)
      at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:752)
      at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1620)
      at org.traccar.web.WebServer.lambda$initClientProxy$0(WebServer.java:126)
      at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
      at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1592)
      at org.traccar.web.OverrideFileFilter.doFilter(OverrideFileFilter.java:55)
      at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
      at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1592)
      at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:89)
      at org.eclipse.jetty.ee10.servlets.DoSFilter.doFilterChain(DoSFilter.java:463)
      at org.eclipse.jetty.ee10.servlets.DoSFilter.doFilter(DoSFilter.java:318)
      at org.eclipse.jetty.ee10.servlets.DoSFilter.doFilter(DoSFilter.java:283)
      at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
      at org.traccar.web.OverrideTextFilter.doFilter(OverrideTextFilter.java:53)
      at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:82)
      at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:121)
      at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:133)
      at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
      at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1592)
      at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1554)
      at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:868)
      at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:449)
      at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:469)
      at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:719)
      at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1224)
      at org.eclipse.jetty.server.Handler$Sequence.handle(Handler.java:859)
      at org.eclipse.jetty.server.Server.handle(Server.java:197)
      at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:720)
      at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:412)
      at org.eclipse.jetty.server.internal.HttpConnection$FillableCallback.succeeded(HttpConnection.java:1810)
      at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
      at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:54)
      at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
      at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
      at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
      at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
      at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
      at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:317)
      at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:1009)
      at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1239)
      at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1194)
      at java.base/java.lang.Thread.run(Thread.java:1583)

The redirect URI is set up in Entra as so:

org.traccar.manager://api/session/openid/callback

I don't see any log entries of interest on the server, even at level 'all'.

OIDC auth is fine via the web.

So I think we're moving forward but still have something else going on.

Thanks for your continued support.

Seems like verification step failed by the provider.

Hi Anton — following up with some additional findings after reviewing Microsoft Entra’s sign‑in diagnostics and comparing them with Traccar’s documented mobile redirect behavior.

The failure appears to be happening inside Microsoft Entra
Microsoft Entra’s sign‑in logs show error 50199, which Microsoft describes as:

“For security reasons, user confirmation is required… repeat the request allowing user interaction.”

Copilot suggests this error is commonly associated with sign‑in loops / inability to complete the interaction step after authentication.

This matches what I’m seeing:

Entra authenticates successfully
But the flow fails when it should return control back to the native app callback

So it seems authentication is succeeding in Entra.

If there’s any Traccar-side diagnostic logging you’d like me to enable/capture around the callback/token exchange, I’m happy to provide it.

Also any further suggestions on tracing on the Entra side would be appreciated.

Thanks!

I don't think Microsoft returns us any additional information. It's just a failed code verification.

Okay, I guess I'll have to give up on the app for now, will have folks use the mobile web page feature instead. If you can make the mobile app callback URL configurable so we can override it to org.traccar.manager://api/session/openid/callback natively then I'll give it another try.

Thank you.

Sorry what? We already changed the callback URL.

Yes you are right, but without additional logging on the Entra side nor the Traccar side I am out of evidence to use to continue troubleshooting whether that change was successful or not or if there is another issue in play. If there is any additional troubleshooting you can suggest I'm all for continuing to troubleshoot.

Thank you

I just want to make sure we don't spread false information for others who read this forum.