Skip to main content

Enables one Django project to authenticate via a second Django project via oauth2.

Project description

Djangito

Enables one Django project (client) to authenticate via a second Django project (server) via oauth2.

Server Installation

  1. pip install djangito # in server virtual environment
  2. Add 'oauth2_provider', 'rest_framework', and 'django_server' to INSTALLED_APPS in settings.py
  3. Add 'users' to INSTALLED_APPS and AUTH_USER_MODEL = 'users.User' in settings.py (only required if you want to use the opinionated Djangito user model)
  4. Add path('o/', include('djangito_server.urls')) to urls.py

Client Installation

  1. pip install djangito # in client virtual environment
  2. Add 'django_client' to INSTALLED_APPS in settings.py
  3. Add 'users' to INSTALLED_APPS and AUTH_USER_MODEL = 'users.User' in settings.py (only required if you want to use the opinionated Djangito user model)
  4. Add path('oidc/', include('djangito_client.urls')) to urls.py
  5. Create an Application on server admin in instance to get DJANGITO_CLIENT_ID AND DJANGITO_CLIENT_SECRET
  6. Add the following to settings.py:
DJANGITO_SERVER_URL = 'https://www.myssoserver.com'
DJANGITO_CLIENT_ID = 'somebignumber'
DJANGITO_CLIENT_SECRET = 'someotherbignumber'

Features

  • Client application redirects user login to server application
  • Client pulls that user's data using oauth2 after logging in ("authorization code" flow)
  • Client will also use user.company.name to update a company ForeignKey field (if it exists)
  • When server data changes, it is POSTed to all the client applications via a JWT (signed using DJANGITO_CLIENT_SECRET)
  • If server User data is deleted, there is (currently) no impact to the client User data
  • Authenticated tokens are one-time use for security purposes i.e., they're immediately delete from the server application after logging in
  • Comes with an opinionated "users" app containing a custom User model. (You can create your own user model. Just add an Integer field called server_id to the User model as well as all associated ForeignKey fields.)

Note: "users" wasn't named "djangito_users" since, per the Django documentation, settings.AUTH_USER_MODEL can't change mid-project. The name "users" is commonly used in tutorials for a custom User model (e.g., how-switch-custom-django-user-model-mid-project).

When is data synced?

  1. Anytime the user logs in from the client application
  2. Anytime the data is modified on the server application (note that just logging into the server application modifies the last_login field)

Why is the traditional approach bad?

  • settings.py grows into unbearable complexity, making it almost impossible to understand app dependencies
  • Can run tests on entire project in development without too much wait time
  • Allows projects to use different databases e.g., SQLite, Postgres
  • Allows projects to use completely different web frameworks
  • Absolute nothing needs to be done to deprecate a project
  • You don't have to share entire code base to employ freelancers
  • Trial new deployment strategies on one features at a time (e.g., main project is on Heroku while a new project is on Elastic Beanstalk)

How logging in works?

  1. settings.LOGIN_URL is monkey patched in djangito_client.models to redirect to client.com/login_handler
  2. login_handler directs to server.com/o/authorize with query string parameters client_id, redirect_uri, scope (i.e., permissions requested), nonce, the original path that initiated the transaction.
  3. server.com/o/authorize (oauth2_provider.AuthorizationView) executes authorization and redirects to callback URI with query string parameters authorization, the original that initiated the transaction
  4. callback_handler gets access token
  5. callback_handler gets user_data from server using the access token
  6. callback_handler creates (or updates) User table using the JSON user data from the server.
  7. callback_handler create a random password for the client database i.e., just a fill to avoid exceptions.
  8. callback_handler calls login(request, u) to login user
  9. callback_handler revokes the token on the server i.e., this simulate one-time-use
  10. callback_handler redirects back to the original URL, now authenticated

How logging out works?

  1. settings.LOGIN_REDIRECT_URL is monkey patched in djangito_client.models to redirect to server.com/o/logout
  2. server.com/o/logout calls logout(request)
  3. server.com/o/logout redirects to client.com

References

Testing Utilities

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

Djangito-0.0.2.tar.gz (16.2 kB view hashes)

Uploaded Source

Built Distribution

Djangito-0.0.2-py3-none-any.whl (20.5 kB view hashes)

Uploaded Python 3

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page