Extending the Application model¶
An Application instance represents a Client on the Authorization server. Usually an Application is issued to client’s developers after they log in on an Authorization Server and pass in some data which identify the Application itself (let’s say, the application name). Django OAuth Toolkit provides a very basic implementation of the Application model containing only the data strictly required during all the OAuth processes but you will likely need some extra info, like application logo, acceptance of some user agreement and so on.
This is the base class implementing the bare minimum for Django OAuth Toolkit to work
client_idThe client identifier issued to the client during the registration process as described in RFC6749 Section 2.2
userref to a Django user
redirect_urisThe list of allowed redirect uri. The string consists of valid URLs separated by space
post_logout_redirect_urisThe list of allowed redirect uris after an RP initiated logout. The string consists of valid URLs separated by space
client_typeClient type as described in RFC6749 Section 2.1
authorization_grant_typeAuthorization flows available to the Application
client_secretConfidential secret issued to the client during the registration process as described in RFC6749 Section 2.2
nameFriendly name for the Application
Django OAuth Toolkit lets you extend the AbstractApplication model in a fashion like Django’s custom user models.
If you need, let’s say, application logo and user agreement acceptance field, you can do this in your Django app (provided that your app is in the list of the INSTALLED_APPS in your settings module):
from django.db import models from oauth2_provider.models import AbstractApplication class MyApplication(AbstractApplication): logo = models.ImageField() agree = models.BooleanField()
Then you need to tell Django OAuth Toolkit which model you want to use to represent applications. Write something like this in your settings module:
Be aware that, when you intend to swap the application model, you should create and run the migration defining the swapped application model prior to setting OAUTH2_PROVIDER_APPLICATION_MODEL. You’ll run into models.E022 in Core system checks if you don’t get the order right.
You can force your migration providing the custom model to run in the right order by adding:
run_before = [ ('oauth2_provider', '0001_initial'), ]
to the migration class.
That’s all, now Django OAuth Toolkit will use your model wherever an Application instance is needed.
Notice: OAUTH2_PROVIDER_APPLICATION_MODEL is the only setting variable that is not namespaced, this is because of the way Django currently implements swappable models. See issue #90 (https://github.com/jazzband/django-oauth-toolkit/issues/90) for details
The default application model supports a single OAuth grant (e.g. authorization code, client credentials). If you need applications to support multiple grants, override the allows_grant_type method. For example, if you want applications to support the authorization code and client credentials grants, you might do the following:
from oauth2_provider.models import AbstractApplication class MyApplication(AbstractApplication): def allows_grant_type(self, *grant_types): # Assume, for this example, that self.authorization_grant_type is set to self.GRANT_AUTHORIZATION_CODE return bool( set([self.authorization_grant_type, self.GRANT_CLIENT_CREDENTIALS]) & grant_types )