The purpose of this refresh endpoint is to get a new token while you still have a valid one.

A common use-case is to call it whenever your user gets back into your app. This way, you ensure you always have a fresh one before the previous expires.

You should call it with a JWT or Cookie (depending on what you use) ; like any other protected endpoint.

thank you!!

From what I see, you recommend to use existing token to refresh it. What if it leaks? The attacker could refresh it indefinitely and due to nature of JWT tokens, you'd be left with no option to revoke it. I think it poses a security threat.

This is exactly why it's not implemented by default in the library. Each developer has the liberty to implement it better.

I see. Well, thanks for clarifying that!

I think a big draw to fastapi-users is how much it does for you. DB setup, routes, forgot-password, (verify email soon 🤞). I think refresh token is a requirement for most projects once they get off the ground, and it seems like a perfect fit to add to this library. For my part, I'm actually going to switch off fastapi-users to fastapi-jwt-auth since it handles refresh tokens. I've wrestled some with how to use fastapi-users for 90%, and defer to fastapi-jwt-auth just for refresh tokens; but it seems it might turn into a Frankenstein, based on how they each handle jwt verification dependency-injection. Instead, I might flip it; use fastapi-jwt-auth as the core, and see about using fastapi-users just for forgot-password & other bits.

All that's to say: we definitely don't want to doubt your decision to defer refresh-tokens to the developer, you're close to the metal and know what's best. But you might find it's a deal-breaker for a lot of people (is for me), who don't know enough jwt/security to tackle this themselves, deferring instead to the experts (yourself). Unless there's some clear path to implementing proper refresh-token flow via fastapi-users on the developers' side that we're not seeing?

Hey @lefnire!

Thank your for the detailed feedback! I totally get your point, and I think you convinced me 😅 I've checked fastapi-jwt-auth and their approach seems indeed interesting (I especially like the freshness pattern).

Now, as you surely know, open-source is hard and time-consuming. I would like to have more time to work on fastapi-users, but I'm quite busy at the moment.

But I promise you that I'll revisit this (and also email verification 😉) when I get time.

I see two ways of implementing this:

• Implement a logic similar to fastapi-jwt-auth in this library ;
• Implement an authentication class backed by fastapi-jwt-auth

I reopen this issue and mark it as enhancement. Thanks ;)

That's wonderful news! Thanks for hearing us out.

open-source is hard and time-consuming

No doubt, and thanks for all your work thus far. We were just concerned it was being marked "out of scope" rather than "help wanted / someday". Hopefully one of us can help!

Implement an authentication class backed by fastapi-jwt-auth

I think that (option 2) is a great idea personally, let them handle some of the guts and fastapi-users can be more the layer on top. Saves dev work, since contribs here can fix bugs there, instead of two places. Actually wonder if / how much of fastapi-users could be refactored to use fastapi-jwt-auth under the hood for current tasks, then you could focus more on the developer-facing features.

One trick worth consideration before work begins. Common practice that refresh tokens use f"{SERVER_SECRET_KEY}{USER_PASSWORD}" as the signing key for refresh tokens (not access tokens). Then what happens is refresh tokens on other devices are invalidated when a user changes their password. No password leakage here, since it's in the signing key (not the returned token). fastapi-jwt-auth doesn't have any example of that, since they're presenting as agnostic to use-case (eg, not just for user accounts). Anyway, two-birds if you do it that way - since someone might open a ticket later "how to invalidate devices when user changes password?"

ocdevel/gnothi#124 if anyone wants to see how to blend fastapi-users + fastapi-jwt-auth to get refresh tokens

@frankie567 - if it's OK, I'd like to have a go at this given this is something I'll be implementing anyway for my project. My suggestion is not to use fastapi-jwt-auth directly because it seems no longer to be maintained (the last commit was 17 months ago) but to create a similar implementation of the freshness token pattern. Would a PR in this direction be welcome?

Hello Folks, excited to read the conversation. Do we have a solution yet?

I've been searching for solution. And found PRs with a lot of changes. In my opinion, it is a little bit dangerous in production to write core logic based on unmerged PRs, so here i want to show my solution (It is a little bit dirty, but it works)
../core/auth_utils.py

def get_auth_router(
    backend: AuthenticationBackend,
    get_user_manager: UserManagerDependency[models.UP, models.ID],
    authenticator: Authenticator,
    get_refresh_strategy: DependencyCallable[Strategy[models.UP, models.ID]],
    requires_verification: bool = False,
) -> APIRouter:
    """Generate a router with login/logout routes for an authentication backend."""
    router = APIRouter()
    get_current_user_token = authenticator.current_user_token(
        active=True, verified=requires_verification
    )

    login_responses: OpenAPIResponseType = {
        status.HTTP_400_BAD_REQUEST: {
            "model": ErrorModel,
            "content": {
                "application/json": {
                    "examples": {
                        ErrorCode.LOGIN_BAD_CREDENTIALS: {
                            "summary": "Bad credentials or the user is inactive.",
                            "value": {"detail": ErrorCode.LOGIN_BAD_CREDENTIALS},
                        },
                        ErrorCode.LOGIN_USER_NOT_VERIFIED: {
                            "summary": "The user is not verified.",
                            "value": {"detail": ErrorCode.LOGIN_USER_NOT_VERIFIED},
                        },
                    }
                }
            },
        },
        **backend.transport.get_openapi_login_responses_success(),
    }

    @router.post(
        "/login",
        name=f"auth:{backend.name}.login",
        responses=login_responses,
    )
    async def login(
        request: Request,
        credentials: Annotated[OAuth2PasswordRequestForm, Depends()],
        user_manager: Annotated[
            BaseUserManager[models.UP, models.ID], Depends(get_user_manager)
        ],
        strategy: Annotated[
            Strategy[models.UP, models.ID], Depends(backend.get_strategy)
        ],
        refresh_strategy: Annotated[
            Strategy[models.UP, models.ID], Depends(get_refresh_strategy)
        ],
    ):
        user = await user_manager.authenticate(credentials)

        if user is None or not user.is_active:
            raise HTTPException(
                status_code=status.HTTP_400_BAD_REQUEST,
                detail=ErrorCode.LOGIN_BAD_CREDENTIALS,
            )
        if requires_verification and not user.is_verified:
            raise HTTPException(
                status_code=status.HTTP_400_BAD_REQUEST,
                detail=ErrorCode.LOGIN_USER_NOT_VERIFIED,
            )
        response = await backend.login(strategy, user)

        refresh_token = await refresh_strategy.write_token(user)
        response.set_cookie(
            "refresh_token", refresh_token, httponly=True, samesite="none"
        )

        await user_manager.on_after_login(user, request, response)
        return response

    logout_responses: OpenAPIResponseType = {
        **{
            status.HTTP_401_UNAUTHORIZED: {
                "description": "Missing token or inactive user."
            }
        },
        **backend.transport.get_openapi_logout_responses_success(),
    }

    @router.post(
        "/logout", name=f"auth:{backend.name}.logout", responses=logout_responses
    )
    async def logout(
        user_token: Annotated[Tuple[models.UP, str], Depends(get_current_user_token)],
        strategy: Annotated[
            Strategy[models.UP, models.ID], Depends(backend.get_strategy)
        ],
        refresh_strategy: Annotated[
            Strategy[models.UP, models.ID], Depends(get_refresh_strategy)
        ],
        refresh_token: Annotated[str | None, Cookie()],
    ):
        user, token = user_token
        if refresh_token:
            try:
                await refresh_strategy.destroy_token(refresh_token, user)
            except StrategyDestroyNotSupportedError:
                pass
        return await backend.logout(strategy, user, token)

    return router

Here i redefined get_auth_router function that provides router with /login and /logout endpoints. I added creating and storing refresh token into refresh_strategy (in my project i use RedisStrategy).

/core/auth.py

...
def get_redis_refresh_strategy() -> RedisStrategy:
    return RedisStrategy(
        redis,
        lifetime_seconds=auth_settings.REFRESH_LIFETIME,
        key_prefix="fastapi_users_refresh_token:",
    )
...

Just created Redis refresh strategy with key prefix for storing refresh_keys

/routers/..../user.py

...
router = APIRouter()


router.include_router(
    get_auth_router(
        auth_backend,
        get_user_manager,
        Authenticator([auth_backend], get_user_manager),
        get_redis_refresh_strategy
    ),
    prefix="/auth/jwt",
    tags=["auth"]
)

...

@router.post("/auth/jwt/refresh", tags=['auth'], response_model=BearerResponse)
async def refresh_token(
    strategy: Annotated[RedisStrategy, Depends(get_redis_strategy)],
    refresh_strategy: Annotated[RedisStrategy, Depends(get_redis_refresh_strategy)],
    refresh_token: Annotated[str | None, Cookie()],
    user_manager: Annotated[UserManager, Depends(get_user_manager)]
):
    if not refresh_token:
        raise HTTPException(status_code=401, detail="Refresh token not provided.")

    user = await refresh_strategy.read_token(refresh_token, user_manager)
    if not user:
        raise HTTPException(status_code=401, detail="Refresh token expired.")

    await refresh_strategy.destroy_token(refresh_token, user)
    new_refresh_token = await refresh_strategy.write_token(user)

    response = await auth_backend.login(strategy, user)
    response.set_cookie('refresh_token', new_refresh_token, httponly=True, samesite='none')
    return response

Here is my definition of /refresh endpoint, where you try to get refresh_token from cookies and renew it, also give new access & refresh to user. Also, there is a leak that i dont try invalidate access token, however it lives for 10 minutes in my case and i see flow as Request -> 401 token expired -> /refresh -> new access. If someone has ideas how to improve this code, you are welcome!