能否为两个Flask-Security实例共用同一认证令牌？

Absolutely, you can share access tokens between your two Flask instances—if your configuration is fully aligned, especially around the settings that control token signing and validation. Let’s break down why your current setup is returning unauthorized and how to fix it.

Core Background: How Flask-Security Auth Tokens Work #

By default, Flask-Security’s auth_token_required uses signed tokens (powered by itsdangerous) to authenticate requests. These tokens are generated using your app’s SECRET_KEY and SECURITY_PASSWORD_SALT to ensure integrity. For a token generated by one instance to be valid on another:

• The signing/validation keys must match exactly across both instances.
• The token’s expiration rules (if configured) must be identical.
• Your user/role models must be structurally the same (since the token encodes user data for validation).

Why You’re Seeing Unauthorized (Likely Causes) #

Even if you’re sharing the same MongoDB database, misalignment in critical configuration settings will break token validation. Here’s what to check first:

1. Mismatched SECRET_KEY #

This is the most common culprit. The SECRET_KEY is the primary key used to sign and verify tokens. If your two instances have different SECRET_KEY values, the second instance will reject tokens generated by the first (it can’t verify the signature).

Verify: Add a quick debug print to both instances to confirm the value is identical:

print("SECRET_KEY:", app.config['SECRET_KEY'])

Ensure this string is exactly the same—no typos, no environment variable differences, no dynamic generation.

2. Mismatched SECURITY_PASSWORD_SALT #

Flask-Security uses this salt alongside the SECRET_KEY when signing tokens. Even a tiny difference here will make tokens unvalidatable across instances.

Verify: Print this value too in both instances:

print("SECURITY_PASSWORD_SALT:", app.config['SECURITY_PASSWORD_SALT'])

3. Token Expiration Mismatch #

If you’ve set SECURITY_TOKEN_MAX_AGE (controls how long tokens are valid), ensure both instances use the same value. A token generated by the first instance might be considered expired by the second if this setting differs.

4. Incorrect Token Delivery #

Double-check that you’re passing the token correctly to the second instance. Flask-Security looks for tokens in two places by default:

• A query parameter named auth_token (e.g., http://second-instance/api/v1/?auth_token=<your-token>)
• An Authorization header with the format Token <your-token>

If your request isn’t sending the token in one of these formats, the second instance won’t pick it up.

5. Inconsistent User/Role Models #

Ensure both instances use identical User and Role models (same fields, same inheritance from UserMixin/RoleMixin). A mismatch here can break token deserialization, even if the signature is valid.

How to Confirm It Works #

Once you’ve aligned all settings, test with a simple curl command to rule out frontend issues:

1. Get a token from your first instance:

   curl -X POST http://first-instance/login -d "email=your-admin@example.com&password=your-password"
   

2. Use that token to hit the second instance’s protected endpoint:

   curl -H "Authorization: Token <your-token>" http://second-instance/api/v1/
   

If this succeeds, your tokens are now shareable.

Final Notes #

• Your shared MongoDB database is only required if you’re using Flask-Security’s trackable features (like SECURITY_TRACKABLE) or if you switch to database-stored tokens (not the default). For signed tokens, the database isn’t needed for validation—just consistent configuration.
• Avoid using plaintext password hashing in production (you’re currently using SECURITY_PASSWORD_HASH='plaintext')—switch to a strong hashing algorithm like bcrypt or argon2.

内容的提问来源于stack exchange，提问作者Rahul