Skip to content

Experiment and document how to use cookies vs headers for JWT tokens #33

Description

@devraj

FastAPI-JWT docs would suggest that you are able to use cookies or headers for authentication.

This is partially being raised because I am unable to get the OTC client to pass headers properly which got me to trying to use cookies instead.

This didn't seem to work (I can see that the client is passing the cookie back and forth).

The preference would be to use headers but it will be worthwhile documenting being able to use cookies as part of FastAPI.

Activity

  1. self-assigned this
    on Aug 11, 2022
  2. devraj commented on Aug 11, 2022

    @devraj
    MemberAuthor

    Switching to cookies involves these steps note the use of

      Authorize.set_access_cookies(access_token)
      Authorize.set_refresh_cookies(refresh_token)

    to set the cookies and

    Authorize.unset_jwt_cookies()

    to unset (logout) the cookie

    Note that in the cookie example the CSRF protection is turned off

    class JWTAuthConfig(BaseModel):
      """A model required by the JWT auth plugin
    
      The FastAPI initialiser registers a decorated instance.
      """
      authjwt_token_location: set = {"cookies"}
      authjwt_secret_key:str = config.JWT_SECRET.get_secret_value()
      authjwt_access_token_expires = False
      authjwt_cookie_csrf_protect: bool = False
  3. devraj commented on Sep 21, 2022

    @devraj
    MemberAuthor

    This particular portion has to do with the client side code, the OTC api clients can be configured to send headers in the following way.

    Moving away from using cookies will allow us to restore CSRF protection in a uniform way (both things being handled by headers)

    OpenAPI.HEADERS = async() => {
      return {};
    }
    
    const appContext: AppContextInterface = {
      apiClient: new AcaciaApiClient(OpenAPI),
      isLoggedIn: false,
      isAdmin: false,
      isStaff: false
    };

    there is merit to documenting both approaches and we should weigh up pros and cons for both.

  4. added
    security-alertidentified as a security vulnerability and requires immediate resolution and pushed downstream
    wontfixThis will not be worked on
    on Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

security-alertidentified as a security vulnerability and requires immediate resolution and pushed downstreamwontfixThis will not be worked on

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions