Token refresh #350

Master-Y0da · 2020-09-29T15:36:03Z

Master-Y0da
Sep 29, 2020

I have many doubts about token refresh implementation in the docs:

     from fastapi import Depends, Response

     @router.post("/auth/jwt/refresh")
     async def refresh_jwt(response: Response, user=Depends(fastapi_users.get_current_active_user)):
          return await jwt_authentication.get_login_response(user, response)

How can I use this function on a real project?...
About "get_current_active_user" -> Will throw a 401 Unauthorized if missing or wrong credentials... by time I call this function the token already expired so the user is Unauthorized ...how could this work ?
What should I send in response param ?

frankie567 · 2020-09-30T06:05:28Z

frankie567
Sep 30, 2020
Maintainer

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.

0 replies

Master-Y0da · 2020-10-01T11:59:04Z

Master-Y0da
Oct 1, 2020
Author

thank you!!

0 replies

izdwuut · 2020-11-12T06:32:12Z

izdwuut
Nov 12, 2020

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.

8000

0 replies

frankie567 · 2020-11-12T06:58:45Z

frankie567
Nov 12, 2020
Maintainer

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

0 replies

izdwuut · 2020-11-12T07:44:05Z

izdwuut
Nov 12, 2020

I see. Well, thanks for clarifying that!

0 replies

lefnire · 2020-11-26T04:04:43Z

lefnire
Nov 26, 2020

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?

0 replies

frankie567 · 2020-11-26T06:49:43Z

frankie567
Nov 26, 2020
Maintainer

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 ;)

0 replies

lefnire · 2020-11-26T07:06:41Z

lefnire
Nov 26, 2020

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!

0 replies

lefnire · 2020-11-26T17:30:16Z

lefnire
Nov 26, 2020

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?"

0 replies

lefnire · 2020-11-29T21:04:40Z

lefnire
Nov 29, 2020

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

0 replies

lefnire · 2020-12-02T17:34:38Z

lefnire
Dec 2, 2020

The {secret_key}{hashed_password} approach via fastapi-jwt-auth might not be currently possible, ticket IndominusByte/fastapi-jwt-auth#26. But he is considering the matter there.

1 reply

ckmaresca May 16, 2021

I'm a bit late to the party on this, but did anyone update the documentation to specify how to use the refresh funcitonality? I'm currently working through this and it would be nice to have an example....

Thanks!

ramsrib · 2021-08-22T03:35:23Z

ramsrib
Aug 22, 2021

Simple and effective way to add refresh endpoint and it worked for me:

https://frankie567.github.io/fastapi-users/configuration/authentication/jwt/#tip-refresh

1 reply

diegocgaona Nov 24, 2021

This method is secure? This solve the problems mentioned by @lefnire ?
Thanks!

BracketJohn · 2022-01-16T22:11:45Z

BracketJohn
Jan 16, 2022

Hey @frankie567,

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

do you already have a rough estimate on the time point you want to re-visit this?

No pressure, or haste or anything like this - the info would just be helpful to me (and possibly others) to see if and for how long I will need to find a work-around for this (:

Thanks for the great library!

2 replies

frankie567 Jan 20, 2022
Maintainer

Unfortunately, I can't give an ETA for this. Actually, all the changes I've made since v8 are steps to allow me achieving this goal, but there are still lot of challenges to overcome.

BracketJohn Jan 20, 2022

No worries, thanks for the reply!

jtv8 · 2022-03-31T08:16:46Z

jtv8
Mar 31, 2022

@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?

0 replies

leandrotoledo · 2022-08-16T16:34:59Z

leandrotoledo
Aug 16, 2022

What are the implications of something like this until an official method is available?

@app.post("/auth/jwt/refresh", tags=["auth"])
async def refresh_jwt(response: Response,
                      authorization: str | None = Header(default=None),
                      user=Depends(fastapi_users.current_user(active=True))):
    if not authorization:
        raise HTTPException(status_code=404, detail="No authorization token found")

    token_type, access_token = authorization.split(" ")

    return await bearer_transport.get_login_response(access_token, response)

2 replies

frankie567 Aug 17, 2022
Maintainer

In the code you show here, you actually don't do anything: you just return the same existing token, you don't refresh it. A working solution would be this:

@app.post("/auth/jwt/refresh", tags=["auth"])
async def refresh_jwt(response: Response, jwt_strategy: JWTStrategy = Depends(get_jwt_strategy), user=Depends(fastapi_users.current_user(active=True))):
    return await auth_backend.login(jwt_strategy, user, response)

Bear in mind though that it's considered as a security flaw because this allows to indefinitely refresh a token. If a malicious attacker steals only one token, they can impersonate the user forever.

vijayvat Jun 28, 2024

how about keep a max refresh count?

enchance · 2023-05-03T05:53:48Z

enchance
May 3, 2023

All your comments are incredibly useful.

@frankie567 What I do is I save the refresh token to any caching server such as Redis and read an httpOnly cookie with the key of refresh_cookie. When refreshing I read the cookie value and check the expiry from Redis to make sure it hasn't been tampered with.

@app.get("/auth/jwt/refresh")
async def refresh_jwt(strategy: Annotated[JWTStrategy, Depends(get_jwt_strategy)], refresh_token: Annotated[str, Cookie()], user=Depends(current_user)):
    valid_token = check_refresh_token(refresh_token)
    if not valid_token:
        raise HTTPException(status_code=401, detail='Invalid token')
    
    token = await strategy.write_token(user)
    return await bearer_transport.get_login_response(token)

You can add your own logic in check_refresh_token() as you see fit.

def check_refresh_token(token: str) -> bool:
    # Check expiry in Redis instead of in cookie
    # If expired then return False

    # Sample
    return True

Is this a good implementation?

8 replies

enchance May 3, 2023

Thinking about it more, regenerating the refresh token all the time seems to "devalue" it purpose as a refresh token. It might be better to just change the token but keep the expiry until such time that it can be fully regenerated.

Then again, I'm feeling things out here so there's a chance it might be analytically useless or practically useful. 😅

jtv8 May 7, 2023

I personally don't see it as a fundamental problem if a token is made perpetually renewable - this provides a smoother UX, and as long as the system designers are aware and mindful of the security trade-offs I think it can be fine.

That said, I think a well designed authentication system should have other measures in place to prevent token theft, including:

Matching the device fingerprint that the previous token was issued to
De-authenticating any access tokens if any token reuse or out-of-order token use is detected
Requiring some sensitive endpoints to be accessed only with a token from a fresh login or fresh multi-factor confirmation (the "freshness pattern")

Some system designers might also want to require users to reauthenticate with a fresh login every N refreshes, or after a maximum amount of time. Storing the number of refreshes and time since last login as metadata in the token claims would help facilitate that.

enchance May 8, 2023

@jtv8 How do you check for token reuse or out-of-order token? What do I look for?

jtv8 May 8, 2023

Basically fastapi-users would need to store the timestamp that the most recent refresh token was issued for a given user account, and refuse to process any refresh tokens that don't have that timestamp in the iat (issued at) claim.

florianabel Jun 20, 2023

@jtv8 How are you receiving your first refresh token, as you would need one in order to refresh, right?

I have been trying to extend the initial login response and add it there, but I haven't found a suitable solution so far.

The alternative option I came up with so far was to receive an initial refresh token on a separate route by providing the access token. However, I feel like this solution is too complex for the problem at hand, and am wondering if there is a better way.

Based on this answer on SO (https://stackoverflow.com/a/69631673) it seems to be the "Standard" way also to provide access and refresh tokens together upon authentication.

Thanks for all the contributions so far btw! Really helped me understand the process better and coming up with a possible solution to this problem.

florianabel · 2023-07-06T16:34:50Z

florianabel
Jul 6, 2023

As mentioned in my reply to enchance above (#350 (reply in thread)) I have been trying to adjust/extend the initial login response to include an initial refresh token in addition to the already provided access token.

Just wanted to share/discuss my solution to help others/find potential pitfalls in this solution. Maybe it is also something that could be implemented in the next version of fastapi-users in a better/easier manner than my current workaround.

@frankie567, I believe that by providing the extra BearerTransportRefresh and extending the Authentication Backend (potentially as an optional argument), we could make it easy to implement the provision of an initial refresh token. What's not yet considered in this approach is potentially storing the initial refresh token in redis etc to implement token rotation.

I am not sure what the current status on the topic is in general and if this is something you'd like to see in the package, especially considering all the work that @jtv8 put in his PR regarding the topic already. Either way, if this is of interest or you'd like some help otherwise, I'd be happy to do a PR or contribute.

This has been my current attempt:

// Extending BearerTransport
class BearerResponseRefresh(BaseModel):
    access_token: str
    refresh_token: str
    token_type: str

class BearerTransportRefresh(BearerTransport):
    async def get_login_response(self, token: str, refresh_token: str) -> Response:
        bearer_response = BearerResponseRefresh(
            access_token=token, 
            refresh_token=refresh_token, 
            token_type="bearer"
        )
        return JSONResponse(bearer_response.dict())

This has led me to extend the AuthenticationBackend (in order to use the extended BearerTransportRefresh)

class AuthenticationBackendRefresh(AuthenticationBackend):
    def __init__(
        self,
        name: str,
        transport: Transport,
        get_strategy: DependencyCallable[Strategy[models.UP, models.ID]],
        get_refresh_strategy: DependencyCallable[Strategy[models.UP, models.ID]]
    ):
        self.name = name
        self.transport = transport
        self.get_strategy = get_strategy
        self.get_refresh_strategy = get_refresh_strategy

    async def login(
        self, 
        strategy: Strategy[models.UP, models.ID],
        user: models.UP,
    ) -> Response:
        token = await strategy.write_token(user)
        refresh_strategy = self.get_refresh_strategy()
        refresh_token = await refresh_strategy.write_token(user)
        return await self.transport.get_login_response(token=token, refresh_token=refresh_token)

and obtaining the extended auth backend

bearer_transport_refresh = BearerTransportRefresh(tokenUrl="auth/jwt/refresh")

def get_jwt_strategy() -> JWTStrategy:
    return JWTStrategy(secret=SECRET, lifetime_seconds=300)

def get_refresh_jwt_strategy() -> JWTStrategy:
    return JWTStrategy(secret=SECRET, lifetime_seconds=259200)

auth_backend_refresh = AuthenticationBackendRefresh(
    name="jwt",
    transport=bearer_transport_refresh,
    get_strategy=get_jwt_strategy,
    get_refresh_strategy=get_refresh_jwt_strategy,
)

fastapi_users = FastAPIUsers[User, int](get_user_manager, [auth_backend_refresh])

2 replies

Afiyetolsun Sep 4, 2023

looks good

Afiyetolsun Sep 6, 2023

Lets works on it

mehmetcc · 2023-10-20T13:40:33Z

mehmetcc
Oct 20, 2023

Hello everyone, any news about this?

1 reply

florianabel Nov 4, 2023

I haven't gotten any response on how to proceed with it (here in the thread). So I didn't touch it any further. I'd love to see this or something similar being implemented though, that'd be really great.
I guess other things have higher priority at the moment though.

@frankie567 could you share some thoughts on where you stand on this when you have a minute to spare?

F438

manish181192 · 2024-01-05T07:24:35Z

manish181192
Jan 5, 2024

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

0 replies

Yue2u · 2024-08-19T13:16:46Z

Yue2u
Aug 19, 2024

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!

0 replies

Token refresh #350

Replies: 20 comments · 17 replies

frankie567 Sep 30, 2020 Maintainer

Master-Y0da Oct 1, 2020 Author

frankie567 Nov 12, 2020 Maintainer

frankie567 Nov 26, 2020 Maintainer

frankie567 Jan 20, 2022 Maintainer

frankie567 Aug 17, 2022 Maintainer

Replies: 20 comments 17 replies

frankie567
Sep 30, 2020
Maintainer

Master-Y0da
Oct 1, 2020
Author

frankie567
Nov 12, 2020
Maintainer

frankie567
Nov 26, 2020
Maintainer

frankie567 Jan 20, 2022
Maintainer

frankie567 Aug 17, 2022
Maintainer