# "No matching state found in storage" after logging in using AzureAD

**URL:** https://community.stadium.software/community/t/no-matching-state-found-in-storage-after-logging-in-using-azuread/169
**Category:** Bug
**Created:** [July 6, 2022, 7:55am UTC](https://community.stadium.software/community/t/no-matching-state-found-in-storage-after-logging-in-using-azuread/169 "2022-07-06T07:55:36Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![anton.platzoeder](https://community.stadium.software/community/user_avatar/community.stadium.software/anton.platzoeder/32/17_2.png) [@anton.platzoeder](https://community.stadium.software/community/u/anton.platzoeder)
#### Post date: [July 6, 2022, 7:55am UTC](https://community.stadium.software/community/t/no-matching-state-found-in-storage-after-logging-in-using-azuread/169/1 "2022-07-06T07:55:37Z")

</div>

I ran into an issue where a user setup his app correct in AzureAD and in the Stadium Application Manager but when he logged in, " No matching state found in storage" was shown.

What happened here was that the user used his IP to navigate to his local SAM, i.e. [https://127.0.0.1:8443/StadiumApplicationManager](https://127.0.0.1:8443/StadiumApplicationManager). The local certificate on SAM is attached to _**[https://localhost:8443](https://localhost:8443/)**_ and everything expects you to use this secured uri. From SAM, the user then used the ‘See it’ hyperlink or ![image](https://community.stadium.software/community/uploads/default/original/1X/f4f8076b560e1dc03f05e88e2ace728b28ddff4d.png) icon to navigate to the application. When clicked, the domain of the server, in this case 127.0.0.1:8443 was used to navigate to the application which then, as expected, was seen as unsecured. In turn, the application redirected to AzureAD for authentication. After logging in, AzureAD redirected to the secured localhost:8443 (as was defined in the AzureAD application) causing the `No matching state found in storage` problem.

Simply using the secured url for SAM and the application, i.e. [https://localhost:8443/StadiumApplicationManager](https://localhost:8443/StadiumApplicationManager) and [https://localhost:8443/NewApplication](https://localhost:8443/NewApplication) , sorted the problem.