Logout and token storage

[downdawn]

Hi, @wu-clan
fastapi/fastapi#7119
fastapi/fastapi#8959
fastapi/fastapi#3580

None of the above discussions have provided a perfect solution.

Here is my idea:

We can use Redis to store tokens with expiration times, support token refresh, and enable features such as single-point login, multi-point login, and distributed deployment.

Tokens can also store additional information, such as role_id, company_id, is_admin, etc. This makes querying more convenient, but there may be security concerns that need to be carefully considered.

Perhaps there are open-source libraries that have already solved these issues.

[wu-clan]

Look here, it should be of great interest

fastapi/fastapi#3305

[wu-clan]

Maybe there's no need to wait for me, I'm just starting to implement

[downdawn]

#57

[wu-clan]

I would like to ask your understanding or opinion on single sign-on and multi-sign-on here.

[downdawn]

Regular users usually use single sign-on (SSO), while some special accounts may require multiple logins, such as shared accounts.

This leads us to another question: we need to implement rate limiting functionality.

[wu-clan]

Yes, including multi-point login restrictions, two new discussions or issues are needed.

[downdawn]

In JWT, a refresh token is used to obtain a new access token, which extends a user's session or access privileges. Refresh tokens have a longer lifespan, typically a few days, compared to access tokens that last only for a few hours.

[downdawn]

For some systems, refresh token is not required.

[wu-clan]

The current refresh is just the specified expiration time, I thought about this during the design, when I added a specified expiration time parameter to the refresh interface, but I'm not sure if I need to do this, currently by two options

1. the default refresh time is X times the specified expiration time
2. the default refresh time is the specified expiration time, add custom expiration time parameter, you can customize the expiration time

Note: Regardless of the option, as soon as the user logs out of the login, all tokens will expire, do you have any other ideas?

Refresh token I think must be provided, in order to front-end automatic update token mechanism, otherwise, whenever the token expires, you must log in again

[downdawn]

I think the second option is more reasonable. You can set the default token expiration time and refresh token expiration time.

The refresh token also expires. Some systems with strong security retain only temporary tokens instead of long-term refresh tokens

So I think refresh token can be made optional

[wu-clan]

Ok, I will submit the PR later

[downdawn]

The front-end returns a token and a refresh token (optional, for features like "Remember Me") during the initial login. When the token expires, the front-end uses the refresh token to request a new token from the API, enabling seamless login.

Therefore, the primary purpose of the refresh token is to obtain a new token, which is typically fixed by the backend for a certain duration, such as 7 or 14 days.

[wu-clan]

OK.

[downdawn]

some pseudocode

    @staticmethod
    async def get_new_token(*, user_id: int, refresh_token: str):
        redis_refresh_token = await redis_client.get(f'{settings.TOKEN_REFRESH_REDIS_PREFIX}:{user_id}:{refresh_token}')
        if not redis_refresh_token and redis_refresh_token != refresh_token:
            raise TokenError(msg='refresh_token 已过期')
        access_token, access_expire, refresh_token, refresh_expire = await jwt.create_access_token(
            str(user_id), refresh=False)
        return access_token, refresh_token, access_expire, refresh_expire

    @staticmethod
    async def logout(*, user_id: int, token: str, refresh_token:str) -> NoReturn:
        key = f'{settings.TOKEN_REDIS_PREFIX}:{user_id}:{token}'
        await redis_client.delete(key)
        refresh_key = f'{settings.TOKEN_REFRESH_REDIS_PREFIX}:{user_id}:{refresh_token}'
        await redis_client.delete(refresh_key)

:param refresh: Whether to generate a refresh token.

If all token records of a user are deleted upon logout, multi-login becomes meaningless.

[wu-clan]

It is recommended to separate the methods of creating tokens and refreshing tokens to reduce coupling.

I want to modify the multi-point login. Add the duplicate login field to the user table to control multi-point login, which is better than the logic of whitelist to control multi-point login.

[downdawn]

Agree!

[wu-clan]

New token processing logic:

• token：For request headers
• refresh_token: Only for creating new tokens

1. Login to create token and refresh_token
2. Create refresh_token dependency token
3. To create a new token must use refresh_token

New multi-point login logic:

Each user contains a multi-login switch, the default is to turn off multi-login

1. When open multi-login, there is no effect on normal users or superusers
2. When close multi-login, ordinary users delete all multi tokens except the one currently in use; when superusers modify themselves, the logic is the same;
3. when superusers modify others, all multi tokens of others are invalidated.

[downdawn]

1. Every time a request is made to determine whether the token is about to expire, the expiration time of the token is updated within a certain threshold.
   Pros: The user experience is good, as long as you continue to operate, you will not be logged out. Only one token is needed, no need to refresh the token.
   Disadvantage: Token is infinitely extended, and the security is not high.

2. After the request, it is found that the token is invalid, and the front end uses the refresh token to obtain a new token, and then continues the previous request.
   Pros: better security
   Bad: general user experience, operation interruption may occur

3. After each request, judge whether the token is about to expire, initiate another request within a certain threshold, and use the refresh token to obtain a new token.
   Pros: User experience and security are okay
   Bad: The refresh token expires, the user still needs to log in again, and the operation may be interrupted

[wu-clan]

Similar to 3, but there should be no need to log in again, just replace the new token

Note: The old token expires only for the current request, the refresh token will not expire immediately and will only contain one per user (even if multi-login), if the refresh token does not exist, just request the refresh token interface to generate a new refresh token, then get a new token with the new refresh token, all this will be done internally again

[downdawn]

When users are performing critical operations, if both the token and refresh token have expired, they need to log in again.

[downdawn]

We can only make some trade-offs, and currently, the third option seems to be a bit more reasonable.

[wu-clan]

When users are performing critical operations, if both the token and refresh token have expired, they need to log in again.

Yes, if it is inactive after a certain period of time, it is inevitable to log in again.

[wu-clan]

Current complete workflow:

1. User login, return token and refresh_token
2. The user sends a request to determine if the token is about to expire
3. Not about to expire, continue the follow-up
4. About to expire, the user requests the get_refresh_token interface to determine whether a refresh_token exists
5. exists, request the refresh_token interface to get the new refresh_token (optional, if you do this, the old refresh_token will be invalid), and request the new_token interface directly through the refresh_token to get the new token, at which point the old token expires
6. Does not exist, request the refresh_token interface to get a new refresh_token, and then request the new_token interface to get a new token, at this time the old token is invalid

Note: If the token expires during this process, refresh_token will have no effect and will cause the authentication to fail and require a new login.

[downdawn]

This process may be too complex for the frontend.

[wu-clan]

The only thing that can be omitted is to eliminate the get_refresh_token interface and use the cached refresh_token expiration time to determine if a refresh_token exists.

Disadvantage: If a new refresh_token is requested elsewhere during multi-login, the cached refresh_token will be invalidated. The solution is not to determine whether the refresh_token exists and create a new one each time.

[downdawn]

If the refresh token has already been returned during the first login, why would there be a need to obtain it again?

[wu-clan]

Because I set it to allow only one refresh_token for a user, multiple logins can be unexpected

[downdawn]

1、User login, receive token and refresh_token.

2、Perform JWT verification on each API request. If the token has expired, return 401.

3、If the frontend receives a 401 response and the refresh token has not expired, use the refresh token to request a new token.

4、Replace the old token with the new token and continue the previous request.

5、If the refresh token has expired or obtaining a new token fails, abandon the subsequent requests and require the user to log in again.

Would this approach be simpler and more logical, in your opinion?

[wu-clan]

If the front-end does global response interception, this will not work and the 401 will be redirected directly to the login page

[downdawn]

Global 401 interception should continue to be processed.

To be careful of:

1. If there is an exception when obtaining a new token, you cannot continue to return 401, and it can be 400.
2. If the front end is a concurrent request, the token may be refreshed repeatedly. Although it does not affect the result, it can still be optimized. The front end can store concurrent queues

[wu-clan]

Agree.

[wu-clan]

I overlooked a key factor, refresh_token will always be valid longer than the token validity time, make the following adjustments:

1. each user can have multiple refresh_token
2. Remove get refresh token and refresh token interface

[downdawn]

Reach a consensus!

[downdawn]

Normal single sign-on users only have one token and refresh token

[wu-clan]

Hi, @downdawn

We need to make some changes to add more unique storage token, for token we can get it from the request header and we can query it anyway, but for refresh_token we can't do some accurate operations on it like deleting it because there is no place to store it.

My idea:

1. use cookie storage
2. add another unique in refresh_token, try to avoid IP, because it does not apply to local debugging and proxy

[downdawn]

In front-end development, tokens and refresh tokens are typically stored persistently in the browser (LocalStorage).

For each request, the token is included in the headers.

As for the refresh token, it is only passed as a parameter when needed, such as when requesting a new token or logging out.

[wu-clan]

Yes, please check this TODO:

fastapi_best_architecture/backend/app/services/user_service.py

Line 141 in ec38c3b

# TODO: 删除用户 refresh token, 此操作需要传参，暂时不考虑实现

I want to handle this automatically in the backend, In other words, I probably don't want to use the pass-parameter implementation here

[downdawn]

Understand, it may be more friendly if it is processed in the back end

Do you have a more specific idea, how to design redis storage? or direct pr

[wu-clan]

#403