Thoughts on creating an ACCESS_TOKEN_GENERATED_LENGTH setting? I assume at some point someone will implement JWT and we'll likely need longer access tokens. It would probably also be nice to set that length on a per-project basis, considering the kind of claims in each project would be different along with the space needed to account for them.
I also think it would be useful to have this setting now, since it's possible, and I'm attempting to, subclass one of OAuthLib's servers and supply my own JWT token generator. However, the token that is generated is too large to fit within the 255 character limit. Even the tiny example JWT on jwt.io is 277 characters long.
I am also investigating issuing JWTs as access tokens. Rather than a length setting, why not switch the field from CharField to TextField? That's easier said than done, obviously; but, seems the safer option to ensure database compatibility.
Ok, here's what I gathered after looking into this:
In oauth2_provider.decorators, the decorators take in a server_cls. This defaults to oauthlib.oauth2.rfc6749.endpoints.pre_configured.Server.
This class takes three arguments we don't make use of:
token_expires_intoken_generatorrefresh_token_generatorWe don't care about the first one for now, but I would like the other two to be exposed.
My suggestion is to make a setting for an importable string for both TOKEN_GENERATOR and REFRESH_TOKEN_GENERATOR.
The charfield size / textfield issue can be rediscussed. I'd like to get custom accesstoken/refreshtoken models in but #252 needs rebasing (and tests, and documentation).
Am I correct in that the contributing guide at https://django-oauth-toolkit.readthedocs.io/en/latest/contributing.html is all that's required to contribute to this effort?
Most helpful comment
I am also investigating issuing JWTs as access tokens. Rather than a length setting, why not switch the field from
CharFieldtoTextField? That's easier said than done, obviously; but, seems the safer option to ensure database compatibility.