Added support for custom JWT types

[scornz]

Added the ability to create tokens with types other than "access" and "refresh", among some other intuitive changes. This is done in such a way that will not introduce any breaking changes. This is useful in such scenarios such as password reset emails, where a JWT needs to be provided to authenticate the user, but an access token and refresh token don't fulfill that purpose.

Summary of changes

• Added create_custom_token with an additional parameter token_type
• Modified verify_jwt_in_request/jwt_required to allow for the additional specification of a token_type
• Modified verify_token_type to check for custom token types, and modified the resulting error messages accordingly.
  • A few tests were modified in order to satisfy these changed error messages.
• Added tests for custom types.
• Swapped the default for non-refresh token expiry time when encoding tokens. This was done to match the way defaults are handled when decoding tokens. Custom tokens will default to access token expiry time if an expires_delta is not provided, instead of the refresh token expiry time as before.

[vimalloc]

Sorry it's taking me so long to look at this, had a bunch of stuff going on. I'll try to get a proper look at this in the next few days.

[josepaiva94]

This would be a nice to have feature. Will it be merged?

[vimalloc]

This would be a nice to have feature. Will it be merged?

Not as is. The breaking change would need to be addressed, and I’m still not sure I like how the API looks for this change, but would be open to feedback on that front. If anyone wants to continue working on this I’m not necessarily opposed to it :+1:

[jaycuse]

I agree this would be nice to have. Found this PR while looking into making a "registration" type token to build out a registration flow using JWT. Based on @tgross35's comments in an other PR, I agree it probably won't be the most used feature and I think it's reasonable to make it slightly less accessible.