Store and manage lifecycle of access tokens beyond authentication #362
+1,436
−5
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* make middleware check more rigid * token integrity validation * don't be so strict on refresh tokens
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I was putting together a solution for my organization in attempt to streamline providing delegated user access to MS Graph APIs to our users who are already authenticated through
django-auth-adfs. After some research into how I was going to do this, I realized that I was not alone in looking for this functionality from this package for one reason or another (#267, #270, #278, #343)While reviewing the materials, I noticed a few reasons why this type of implementation was not added to the package yet, even as there was some interest from at least one of the maintainers.
I was still going to need this solution, so with all of that in mind I landed on a design that I would feel comfortable contributing to this project for consideration. While it's originally designed to solve the needs of my organization, I realize those needs are not unique, so I propose this Middleware as a solution in fulfillment of these needs while also addressing concerns of @tim-schilling in #343
✅ Move as much of the new changes to the middleware and out of the backend
✅ Only store the token information in the session if the refresh token middleware is being used (not sure the best way here)
✅ Prevent the library from storing tokens in the session if cookie based sessions are being used
✅ There needs to be some documentation
In spirit of keeping things contained to the middleware, all the related functionality has been implemented in a manager class singleton and the
backend.pywas only adjusted to call this during the authentication flow, providing the request in case we want to store tokens on their session, and safely determine if the middleware is enabled before trying to perform any operations surrounding this functionality.Otherwise, if you don't enable the middleware in your application, nothing should be any different, and you won't be forced to have the tokens managed or stored on the sessions if you don't want that.
Sphinx documentation has been provided
Unit tests have been generated (in attempt) to maintain integrity, but maybe some more work could be done there
Open to discussion/feedback/critiques etc.
I understand if it's not in the interest of the maintainers to have the package operate in this scope.
Thank you for your time and consideration