Support two simultaneous token configs

[edv4rd0]

This is the situation:

• Users are authenticated via httpOnly JWT cookies with double submit csrf cookies (refresh tokens as well).
• API clients use Authorization bearer tokens with IP whitelisting and no CSRF tokens (limited scope of operations, public API etc). The bearer token is sent to the API as JSON payload after they request an access token using their secret JWT refresh token.

I'm wondering how to go about supporting this. It's possible I have a stupid idea here though.

[vimalloc]

If I understand you correctly, the crux of your problem is that you want to have some users access your protected endpoints with the tokens in cookies, and some users accessing endpoints with tokens in headers. Is that right?

If so, you can actually pass in a list to JWT_TOKEN_LOCATION, such as ['headers', 'cookies'], which will cause your jwt_required endpoints to accept either, as long as they are present in one place or the other.

If I'm misunderstanding you here, let me know :)

[edv4rd0]

That's a part of it.

I'm wanting one group of users (actual human users) to only be able to access endpoints (via a SPA) using cookies with CSRF double submit cookies. However, the second set of users (API client code) to use Authorization header bearer tokens with no CSRF double submit cookies.

The second group would be external users' systems access some of our exposed API endpoints for data.

[vimalloc]

if JWT_TOKEN_LOCATION = ['headers', 'cookies'] and JWT_COOKIE_CSRF_PROTECT = True, the csrf double submit protection is only applicable to the tokens being passed in via cookies. When decoding tokens passed in from headers, csrf protection is not checked:

https://github.com/vimalloc/flask-jwt-extended/blob/master/flask_jwt_extended/view_decorators.py#L127

[edv4rd0]

Cool. It would be nice to restrict the cookie tokens from being sent by headers, I could probably add a flag into the payload though I guess.

BTW, nice code base - very readable library.

[vimalloc]

Thanks! :)

I think implementing that in your application would make more sense then having it be a feature of this extension. The reason I say that is there might be other cases where someone wants the same endpoints to be accessed by tokens in headers and cookies, for example a SPA using cookies and a mobile app using headers.

[edv4rd0]

One thing that would be helpful would be being able to have two token configs for different expiry times etc based on the token type and purpose. It's currently hardcoded to get the extension from app.jwt_manager so setting up a second manager object will not work as the extension's module functions pull in the current app and look at that variable.

[vimalloc]

I think building out the ability to have two separate configs in here would greatly complicate the code. I do have a couple ideas for alternatives though.

The first would be to add additional kwargs into the create_access_token and create_refresh_token that allow you to override options set in the application. Something like:

expires = datatime.timedelta(hours=24)
access_token = create_access_token(username, expires_delta=expires)

I don't think it would be good to allow changing of the secret_key, csrf, or algorithm here (as we would then need to have a way to also update those on decode calls, and that starts to get messy). That leave the identity, expires_delta, fresh, and user_claims, which after this change, should all be able to be tweaked by either kwargs passed into the create_*_token calls (fresh and expires_delta kwargs), or by callback methods you can register (user_identity_loader and user_claims_loader).

The second way, which I'm not sure would actually solve this problem or not (or work at all for that matter), would be to use Flask Application Factories in conjunction with blueprints. Something along the lines of creating multiple flask applications that have different configs, and register the same code (expect for where you need the differences) via blueprints but with different base urls.

I think the first idea should probably be enough here, and it sounds like it would be a helpful addition to this extension. If that sounds good to you, I can work on getting that added.

[vimalloc]

I've got this implemented. I'll get a new release with it pushed out soon.

[edv4rd0]

Wow, I'm impressed with the fast turnaround. Yes, that pretty much covers most of what I needed and will seriously reduce the complexity of my code. Thanks :-)

[vimalloc]

Anytime :) This has been released as version 2.3.0 and should be showing up on pypi shortly.

Let me know if you run into any issues with this.

Cheers!