Skip to main content

Django-oauth-toolkit-cookie-refresh

CI tests Package Downloads

Django-oauth-toolkit-cookie-refresh is a Django app to that provides REST authentication endpoints which uses refresh token in httpOnly cookie. It relies on Django REST framework and Django Oauth Toolkit.

Motivation

The django-oauth-toolkit by default sends back access token and refresh token both in response body. This presents a dilemma for web developers as to where to store/persist each token:

  • Web storage (local storage and session storage) is accessible through Javascript on the same domain, this presents an opportunity for malicious scripts running on your site to carry out XSS against your user clients, which makes web storage not ideal for storing either access or refresh tokens. There are a large number of scenarios where XSS can take place, and a number of ways to mitigate them. you can read more about XSS here.
  • Cookies with HttpOnly flag are not accessible by Javascript and therefore not vulnerable to XSS, however they may be the target of CSRF attack because of ambient authority, where cookies may be attached to requests automatically. Even though a malicious website carrying out a CSRF has no way of reading the response of the request which is made on behalf of a user, they may be able to make changes to user data resources if such endpoints exist. This makes HttpOnly cookies unsuited for storing access token. There are several ways to mitigate CSRF, such as setting the SameSite attribute of a cookie to "Lax" or "Strict", and using anti-CSRF token. You can read more about CSRF here.

In addition to various XSS and CSRF mitigation techniques, this package deploys access token and refresh token for web apps in a specific way that broadly hardens application security against these attacks:

  • Access tokens, are as usual, send back to clients in response body. It is expected that you would design your frontend application to not persist access tokens anywhere. They are short-lived and only used by the SPA in memory, and are tossed as soon as the user close the browser tab. This way, the access token cannot be utilized in a CSRF attack against your application.
  • Refresh tokens, are sent back to client in a HttpOnly cookie header that the client browser sees but inaccessible by your own frontend application. This way, the refresh token is not subject to any XSS attack against your application. While CSRF is possible, the attacker cannot use this mechanism to make modification to your resources even is a CSRF attack is successfully carried out. It is important to note that in CSRF, the attacker cannot read the response even when they successfully make the malicious request to your API endpoint; the worst they can do is to refresh the token on user's behalf, and no damage can be done. The refresh token cookie would also typically have domain and path attributes specified, so that browsers should only attach them with request to your domain and specific url path used for refreshing the tokens, therefore reducing attack surfaces further.

Quick start

Install using pip:

pip install django-oauth-toolkit-spa

Or, install from source:

Set up django-oauth-toolkit and django REST framework if you haven't already:

INSTALLED_APPS = (
    'django.contrib.admin',
    ...,
    'oauth2_provider',
    'rest_framework',
)
REST_FRAMEWORK = {
    'DEFAULT_AUTHENTICATION_CLASSES': (
        'oauth2_provider.contrib.rest_framework.OAuth2Authentication',
    )
}

Include the oauth_toolkit_spa URLconf in your project urls.py:

path('auth/', include('oauth_toolkit_spa.urls')),

Settings

django-oauth-toolkit's settings are largely extended and used, except few default values have been overwritten. These settings are used as default unless explicitly specified:

"ACCESS_TOKEN_EXPIRE_SECONDS": 300,
"REFRESH_TOKEN_EXPIRE_SECONDS": 36000,
"REFRESH_COOKIE_NAME": "refresh_token",
"REFRESH_COOKIE_PATH": "/auth"

You can modify these settings by specifying them in the settings for django-oauth-toolkit:

OAUTH2_PROVIDER = {
    ...,
    "ACCESS_TOKEN_EXPIRE_SECONDS": 300,
    "REFRESH_TOKEN_EXPIRE_SECONDS": 36000,
    "REFRESH_COOKIE_NAME": "refresh_token",
    "REFRESH_COOKIE_PATH": "/auth",
    ...
}

If you want to use a different path for authentication than the default path, you should provide the setting in REFRESH_COOKIE_PATH, using a string with leading slash /; while provide the same path in URLconf but with a trailing slash /.

Metadata

Release files for django-oauth-toolkit-spa 1.0.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for django-oauth-toolkit-spa 1.0.1
File Size Uploaded Provenance
django-oauth-toolkit-spa-1.0.1.tar.gz 7.4 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for django-oauth-toolkit-spa 1.0.1
File Interpreter ABI Platform
django_oauth_toolkit_spa-1.0.1-py3-none-any.whl Python 3 none any Details

Total release size: 16.5 kB

Release files / django-oauth-toolkit-spa-1.0.1.tar.gz

Download URL django-oauth-toolkit-spa-1.0.1.tar.gz
Size 7.4 kB
Tags Source
SHA-256 checksum
How to use checksums
98b17d62cbf8714a6c58de44104c2ede1e6ef11796cd6a8525ee9f7b67bc58a9
BLAKE2b-256 checksum
How to use checksums
07c75e980596ce906fa31e0aa2e8b92fac4220ba9c004570b87080d0e412fb66
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.2 CPython/3.8.16

Release files / django_oauth_toolkit_spa-1.0.1-py3-none-any.whl

Download URL django_oauth_toolkit_spa-1.0.1-py3-none-any.whl
Size 9.1 kB
Tags Python 3
SHA-256 checksum
How to use checksums
83ed51b58388e7ac1f9d8c15b0eba501e393e54a14f5543c6f5f139c951cfab0
BLAKE2b-256 checksum
How to use checksums
dcd48f94d32a85d94a2ddcf6ca419a059c91bbf0a9850259af6a8adee27e1e3f
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.2 CPython/3.8.16

Security for django-oauth-toolkit-spa 1.0.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

1.0.1 This release

2 release files No provenance

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page