I have the example deployed on azure exactly as is except for changing app_config.py. In that file I saw:

# Tells the Flask-session extension to store sessions in the filesystem
SESSION_TYPE = "filesystem"
# Using the file system will not work in most production systems,
# it's better to use a database-backed session store instead.

It is unclear whether you changed that app_config.py file or not, and if so, what was your change.

The thing is that I have a very simple application with which I want to allow a user to sign in and, after they are, run a process for which I don't need a database.

Is there a recommended way to implement this if no database is used?

The mentioning of database in app_config.py was a suggestion. But if you keep its default value "filesystem", it would still work. We have tested it that way.

I'm getting a state mismatch error when attempting to sign in

Could it be possible that you also modified this sample in some other way? Also, what is your configuration (you do not need to tell us your app's client_secret)? What is the output of pip list in your environment?

Thank you for the quick and helpful reply @rayluo! My app_config.py looks like this:

import os
AUTHORITY = os.getenv("AUTHORITY")
CLIENT_ID = os.getenv("CLIENT_ID")
CLIENT_SECRET = os.getenv("CLIENT_SECRET")
REDIRECT_PATH = "/auth/redirect"
SCOPE = ["User.Read"]
SESSION_TYPE = "filesystem"

My environment variables are these (I changed some values to zeros to not share them publicly):

[
 {
 "name": "AUTHORITY",
 "value": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000",
 "slotSetting": false
 },
 {
 "name": "CLIENT_ID",
 "value": "00000000-0000-0000-0000-000000000000",
 "slotSetting": false
 },
 {
 "name": "CLIENT_SECRET",
 "value": "0000000000000000000000000000000000000000",
 "slotSetting": false
 },
 {
 "name": "SCM_DO_BUILD_DURING_DEPLOYMENT",
 "value": "1",
 "slotSetting": false
 }
]

You mentioned pip list, which made me realise that I have been testing out different things so perhaps I've installed some packages which cause conflicts. Here is the output of pip list:

Package Version
-------------------- ----------
appsvc-code-profiler 1.0.0
blinker 1.7.0
cachelib 0.10.2
certifi 2023年11月17日
cffi 1.16.0
charset-normalizer 3.3.2
click 8.1.7
cryptography 41.0.7
debugpy 1.6.7
distlib 0.3.7
filelock 3.12.2
Flask 3.0.1
Flask-Session 0.5.0
gunicorn 20.1.0
identity 0.3.2
idna 3.6
itsdangerous 2.1.2
Jinja2 3.1.3
markdown-it-py 3.0.0
MarkupSafe 2.1.3
mdurl 0.1.2
msal 1.26.0
objprint 0.2.2
orjson 3.8.1
pip 23.0.1
platformdirs 3.10.0
psutil 5.9.5
pycparser 2.21
Pygments 2.16.1
PyJWT 2.8.0
python-dotenv 0.21.1
requests 2.31.0
rich 13.5.2
setuptools 65.5.0
subprocess32 3.5.4
urllib3 2.1.0
virtualenv 20.24.2
vizplugins 0.1.3
viztracer 0.15.6
Werkzeug 3.0.1
wheel 0.40.0

What I have noticed is that after I go through the sign in process I'm redirected to /login. However, after signing in, when I change the URL by removing the /login part (so going to the index page), I do see my username. So it does recognise I am signed in. Only once though, because when I refresh the page I no longer see my name and instead get redirected to /login.

Something I'm confused about though. You write:

The mentioning of database in app_config.py was a suggestion. But if you keep its default value "filesystem", it would still work.

But the app_config.py file mentions:

Using the file system will not work in most production systems

Saying it will not work on most production systems reads to me more like a requirement than a suggestion, but just to confirm: using the file system for sessions should work when deployed as an azure web app?

Something I'm confused about though. You write:

The mentioning of database in app_config.py was a suggestion. But if you keep its default value "filesystem", it would still work.

But the app_config.py file mentions:

Using the file system will not work in most production systems

Saying it will not work on most production systems reads to me more like a requirement than a suggestion, but just to confirm: using the file system for sessions should work when deployed as an azure web app?

File system does not scale well, database does, that's why it is a suggestion to use database in production. And if you happen to build a popular website that has busy workload, file system may not keep up with your workload, your website may feel unresponsive. At that point, using database would become a requirement - required by your workload. But until then, file system is functionally adequate. We tested this sample app with its default file-system setting and it should work.

At the least, the file-system VS database shall not result in different behavior if you are deploying to only one server.

Which brings me to my next question. How many web servers are you currently using in your setup? I ask this because,

My environment variables are these (I changed some values to zeros to not share them publicly):

[
 {
 "name": "AUTHORITY",
 "value": "https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000",
 "slotSetting": false
 },

the shape of your configuration file is different than an .env, so you are probably using some sort of cluster solution, which provisions multiple web servers. And since all of those web servers use file system to store sessions, they do not share the same session pool. It is therefore likely that your first request successfully signed in on machine A, but then your subsequent request randomly landed on machine B whose file system does not contain your session in machine A. In such a case, yep, you are required to use database among those machines to serve as a unified session storage.

Thank you for the quick and helpful reply @rayluo!

By the way, you think my previous response within 8 hours was quick? How about this new response with 48 minutes, in an early Saturday morning in my timezone? :-) That said, now I need to catch some sleep. Yawn.

Small update: in the end I will keep using the filesystem. This seems to work well in combination with using the affinity cookie to ensure users are sent to the same instance for subsequent requests.

ARR cleverly identifies the user by assigning them a special cookie (known as an affinity cookie), which allows the service to choose the right instance the user was using to serve subsequent requests made by that user. This means, a client establishes a session with an instance and it will keep talking to the same instance until his session has expired.

https://azure.github.io/AppService/2016/05/16/Disable-Session-affinity-cookie-(ARR-cookie)-for-Azure-web-apps.html

Small update: in the end I will keep using the filesystem. This seems to work well in combination with using the affinity cookie to ensure users are sent to the same instance for subsequent requests.

ARR cleverly identifies the user by assigning them a special cookie (known as an affinity cookie), which allows the service to choose the right instance the user was using to serve subsequent requests made by that user. This means, a client establishes a session with an instance and it will keep talking to the same instance until his session has expired.

https://azure.github.io/AppService/2016/05/16/Disable-Session-affinity-cookie-(ARR-cookie)-for-Azure-web-apps.html

Thanks for sharing! Yep, affinity cookie is also another excellent solution. I'll add this learning into this sample's configuration file soon.

P.S.: This response came within 37 minutes. :-)