This PR add OpenID Connect Core http://openid.net/specs/openid-connect-core-1_0.html support.

To run the tests do:

Django OAuth Toolkit cloned repository

git remote add [email protected]:wiliamsouza/django-oauth-toolkit.git wiliamsouza
git checkout -b openid-connect wiliamsouza/openid-connect
tox

Usage examples:

Authorization-code

http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth

token and id_token

http://127.0.0.1:8000/o/authorize?response_type=code&client_id=HCSTniKnHNj6qP6Dkms39q6IT4pahzfXws2uwTkS&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

Only token

http://127.0.0.1:8000/o/authorize?response_type=code&client_id=HCSTniKnHNj6qP6Dkms39q6IT4pahzfXws2uwTkS&redirect_uri=http://localhost/callback&scope=read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

curl -X POST \
    -H "Cache-Control: no-cache" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    "http://127.0.0.1:8000/o/token/" \
    -d "client_id=HCSTniKnHNj6qP6Dkms39q6IT4pahzfXws2uwTkS" \
    -d "client_secret=Ay1rH78PChsOG4mshfdp2oJnomdpu5Vgtdz6jCmDkEM8mKHzcaKo5GEYNGK42KTN8XqEWbbpn1vdHJKYcBgawONx4S1xXY7GtEP9mvsMw593DeXH0aRpWlgySuxeDfe2" \
    -d "code=89BRsh4kQqrwlNMLj4coVZbrpDm0Mh" \
    -d "redirect_uri=http://localhost/callback" \
    -d "grant_type=authorization_code"

implicit

http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth

token

http://127.0.0.1:8000/o/authorize?response_type=token&client_id=Ktn0Sh4hO2gA8PKC2aqsauY4ZCxNyIdF1wNfFfJ3&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

id_token

http://127.0.0.1:8000/o/authorize?response_type=id_token&client_id=Ktn0Sh4hO2gA8PKC2aqsauY4ZCxNyIdF1wNfFfJ3&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

token and id_token

http://127.0.0.1:8000/o/authorize?response_type=id_token%20token&client_id=Ktn0Sh4hO2gA8PKC2aqsauY4ZCxNyIdF1wNfFfJ3&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

openid-hybrid

http://openid.net/specs/openid-connect-core-1_0.html#HybridFlowAuth

code, id_token and token

http://127.0.0.1:8000/o/authorize?response_type=code%20id_token%20token&client_id=fZjUvm0YABo6mX1UTjo9VVYay9zj1HpaCZaoa4Fj&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

code and id_token

http://127.0.0.1:8000/o/authorize?response_type=code%20id_token&client_id=fZjUvm0YABo6mX1UTjo9VVYay9zj1HpaCZaoa4Fj&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

code and token

http://127.0.0.1:8000/o/authorize?response_type=code%20token&client_id=fZjUvm0YABo6mX1UTjo9VVYay9zj1HpaCZaoa4Fj&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

code

http://127.0.0.1:8000/o/authorize?response_type=code&client_id=fZjUvm0YABo6mX1UTjo9VVYay9zj1HpaCZaoa4Fj&redirect_uri=http://localhost/callback&scope=openid%20read&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj

curl -X POST \
    -H "Cache-Control: no-cache" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    "http://127.0.0.1:8000/o/token/" \
    -d "client_id=fZjUvm0YABo6mX1UTjo9VVYay9zj1HpaCZaoa4Fj" \
    -d "client_secret=eiBw6IIQ4zzWFP9gSszEHZwexjCDhJjMtRxoOYQexCJMjQ6gdyN2ME9aUzbGkVopx3NSZRPUb4SV9yKpbVwwW9NKdEpkoyGmcTni7G4KTPqtJrsI9HPubFnDDzsvAf89" \
    -d "code=VQGv7tzYGO13jrRnv6oYT7jHbDSGJZ" \
    -d "redirect_uri=http://localhost/callback" \
    -d "grant_type=authorization_code"

TODO:

• [ ] Create/Update docs
• [x] Merge OAuthLib PR https://github.com/idan/oauthlib/pull/488

It would be convenient for me to not tied a User to Application for credentials grant this way the access token could be associated to None or AnonymousUser (I've applied a hack in my validate_bearer_token validator in the meantime).

why the User is required in this model?

Hello,

I was waiting for the approval of the OpenID Connect spec, and now it's approved, I wonder if you would like a pull request with that feature (the "OpenID connector" part on your roadmap refers to that, right?)

I'm already learning the Core spec to figure out how it can be implemented. It seems like a thin layer on top of OAuth2, for example the authentication part is done by a request to /o/authorize with "openid" as one of the scopes, and the token exchange now returns one more parameter, the ID Token.

There's two more (optional) specs, but my intent is implement the core on top of django-oauth-toolkit, since it seems enough to be an OpenID provider. I'm already reading django-oauth-toolkit's source code, but any tips are welcome.

So, what do you think?

** Please do not squash the commits. I analyse my FOSS contributions automatically and really want to track commits I made.**

Description of the Change

This is a second shot at #967, after the drama with #1066 and #1068 ;).

It re-introduces the same change @AndreaGreco proposed, and in fact, it supports their exact desired API for get_additional_claims. In addition, it supports the "traditional" API for get_additional_claims getting passed a request directly and producing data directly.

I chose to support both due to the rationale explained in the docs in this PR.

Checklist

• [x] PR only contains one change (considered splitting up PR)
• [x] unit-test added
• [x] documentation updated
• [x] CHANGELOG.md updated (only for user relevant changes)
• [x] author name in AUTHORS

Fixes #1037

Description of the Change

Add support for Dj40, drop Py36 and Dj31

Dj31 and Py36 will be EOL end of this December of 2021. I do not want to hold back any PRs that need to support old versions of stuff, thus I have dropped those two.

Checklist

• [X] PR only contains one change (considered splitting up PR)
• [ ] unit-test added
• [ ] documentation updated
• [ ] CHANGELOG.md updated (only for user relevant changes)
• [X] author name in AUTHORS

We are looking forward to using django-auth-toolkit with Django 3.2

Required PR is already merged into master branch #968. Do there any chance a new version will be bumped soon?

If any blockers with the release I would be happy to help.

Thank you in advance.

These add a couple more permission classes for scope matching. TokenHasMethodScope allows specifying required scope(s) on a per-method basis (in the case where READ_SCOPE and WRITE_SCOPE are not granular enough) and TokenHasMethodPathScope adds regex path matching and alternative lists of required scopes for a given regex match which is aligned with OpenAPI Spec (OAS) security requirement object list of alternative matching:

"When a list of Security Requirement Objects is defined on the Open API object or Operation Object, only one of Security Requirement Objects in the list needs to be satisfied to authorize the request."

Adding the OAuth2TokenMiddleware to the MIDDLEWARE array will break the application: Traceback (most recent call last): ... File "/var/www/brownpapersession/dev/env-brownpapersession/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 82, in load_middleware mw_instance = middleware(handler) TypeError: object.__new__() takes no parameters

Mitigation described here: https://docs.djangoproject.com/en/1.10/topics/http/middleware/

Hello,

I'm following the tutorial for Django Rest Framework. I set up my application in the admin and I'm sending a POST request just like in the tutorial, but always get

{"error": "invalid_client"}

as a response:

$ curl -vK user -X POST -d "grant_type=password&username=myuser&password=mypass" http://localhost:8000/o/token/
* About to connect() to localhost port 8000 (#0)
*   Trying 127.0.0.1...
* connected
* Connected to localhost (127.0.0.1) port 8000 (#0)
* Server auth using Basic with user 'RgmI&_Y A5mdjuAh2T/]m_ZeD|u'[8`$r|`k'!'
> POST /o/token/ HTTP/1.1
> Authorization: Basic UmdtSSZfWSBBNW1kanVBaDJUL11tX1plRHx1J1s4YCRyfGBrJyE6dnZdWWw/LUB3YWNBI2Q+NEcyNWEkbkZCclogJGQ/e1ZtYm4rMl5GYnRNSl9ZTitiVHB6b3UjXkRdaFhMeGxNL28jJz95MCV0ZXQ8Z3w8OEZTZHVPMkIvN3Y6dG5EUz99ZGxla3B2dTchWTssJDA8VEQ1UmwucA==
> User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
> Host: localhost:8000
> Accept: */*
> Content-Length: 55
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 55 out of 55 bytes
* HTTP 1.0, assume close after body
< HTTP/1.0 400 BAD REQUEST
< Date: Sun, 08 Sep 2013 17:30:37 GMT
< Server: WSGIServer/0.1 Python/2.7.5
< Content-Language: it
< Vary: Accept-Language, Cookie
< Pragma: no-cache
< Cache-Control: no-store
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/json;charset=UTF-8
< 
* Closing connection #0
{"error": "invalid_client"}

Consider an oauth-toolkit setup using password for grant_type. A user can brute force the password and oauth toolkit has no mechanism to avoid brute force (at least I didn't find anything.) I guess we should add a throttling or something similar.

Because I want to be able to implement custom AccessToken and RefreshToken models, I've implemented a customizable AccessToken and RefreshToken, in the same way that the Application model was already configurable via the settings

Description of the Change

Replaces deprecated tox.ini whitelist_externals with allowlist_externals. This is breaking any new PR as of the tox version upgrade.

Checklist

• [x] PR only contains one change (considered splitting up PR)
• [ ] unit-test added
• [ ] documentation updated
• [ ] CHANGELOG.md updated (only for user relevant changes)
• [x] author name in AUTHORS

I am working with Django Oauth2 on a freelancing project and used the username and password to handle authenticate users.

However, when I tried to refresh the access token I noticed that the refresh_token itself was revoked, and I found on the documentation that we can use ROTATE_REFRESH_TOKEN to disable this behavior.

But, the docs are talking about a known bug that I do not fully understand, why would setting this setting to False because the tokens are to be revoked, I debugged the code locally and didn't see anything that would cause this.

I suspect that the docs could be old, and a bit outdated in that regard, but not sure.

Can someone please explain it to me, and if it is safe to use when going into production or not?

Describe the bug

I'm using next-auth on the frontend and the latest django-oauth-toolkit with OIDC enabled and HS256 as the algorithm on the backend. After authorizing my oauth application I get the error "failed to validate JWT signature" in next-auth.

The JWT token provided by django-oauth-toolkit seems to be incorrect. It's prepared in oauth2_provider.oauth2_validators.finalize_id_token. The culprit is the jwk_key that's used for signing the token. It's generated with the client secret, which is being hashed since v2.0.0.

https://github.com/jazzband/django-oauth-toolkit/blob/04b5b3e49020168d8decc2c536f3287ad40bcfc3/oauth2_provider/oauth2_validators.py#L845

I'm assuming that hashing was added under the assumption that the raw secret isn't needed anymore after it's created, but that doesn't seem to be the case (see line 224).

https://github.com/jazzband/django-oauth-toolkit/blob/04b5b3e49020168d8decc2c536f3287ad40bcfc3/oauth2_provider/models.py#L217-L225

To Reproduce

I've created a test repo: https://github.com/dnsv/auth-test

1. Setup Django (I'm using Python 3.11):

   1. poetry install
   2. poetry run python manage.py runserver
   3. poetry run python manage.py migrate
   4. poetry run python manage.py createsuperuser.

2. Login into admin.

3. Create a new Oauth application:

   • Redirect urls: http://localhost:3000/api/auth/callback/test
   • Client type: Confidential
   • Authorization grant type: Authorization code
   • Algorithm: HMAC with SHA-2 256

4. Create the file frontend/.env:

   OAUTH_CLIENT_ID=...
   OAUTH_CLIENT_SECRET=...
   

5. Setup Next.js (I'm using node v18.12.1, but i probably works the same with lower versions).

   1. cd frontend
   2. yarn install
   3. yarn dev

6. Go to http://localhost:3000/ and try to sign it. You'll get the error shown in the console after the authorization step.

Highlights from the backend setup:

# backend/base/settings.py

OAUTH2_PROVIDER = {
    "OIDC_ENABLED": True,
    "OAUTH2_VALIDATOR_CLASS": "backend.oauth2.utils.CustomOAuth2Validator",
    "SCOPES": {
        "openid": "OpenID Connect scope",
    },
}

# backend/oauth2/utils.py

from oauth2_provider.oauth2_validators import OAuth2Validator

class CustomOAuth2Validator(OAuth2Validator):
    oidc_claim_scope = None

    def get_additional_claims(self, request):
        return {
            "id": request.user.id,
            "given_name": request.user.first_name,
            "family_name": request.user.last_name,
            "name": f"{request.user.first_name} {request.user.last_name}",
            "email": request.user.email,
        }

Expected behavior

Being able to login :)

Version

• [x] I have tested with the latest published release and it's still a problem.
• [ ] I have tested with the master branch and it's still a problem.

Additional context

N/A

Describe the bug

In DOT 2.x the client_secret is now stored hashed. Documentation (including warning text in the HTML template) was added for the admin UI but was missed for the documentation and non-admin UI endpoints as documented in getting_started

To Reproduce

1. Run a DOT-using app
2. Go to http://127.0.0.1:8000/o/applications/register/
3. Note that there's no clear warning about copying the client_secret before save as there is in the admin UI.

Expected behavior

The user should be warned to copy the secret before save as is done at http://127.0.0.1:8000/admin/oauth2_provider/application/add/

Version

2.2.0

• [x] I have tested with the latest published release and it's still a problem.
• [x] I have tested with the master branch and it's still a problem.

Additional context

See #1235 although that issue says the unhashed secret was used so the error may be unrelated.

Hello. I have an error. Maybe django-oauth-toolkit's error.

1. Create a token.
2. And a re-create a token.
3. But second token occur a duplicate key error.

pymongo.errors.BulkWriteError: batch op errors occurred, full error: {'writeErrors': [{'index': 0, 'code': 11000, 'keyPattern': {'source_refresh_token_id': 1}, 'keyValue': {'source_refresh_token_id': None}, 'errmsg': 'E11000 duplicate key error collection: test.oauth2_provider_accesstoken index: source_refresh_token_id dup key: { source_refresh_token_id: null }', 'op': {'id': 29, 'user_id': ObjectId('63aa59667ef2477a5517c897'), 'source_refresh_token_id': None, 'token': 'GD8Uq4vupSPV2t0BbZ5D0joTbQrIhH', 'id_token_id': None, 'application_id': 1, 'expires': datetime.datetime(2022, 12, 27, 12, 52, 50, 819549), 'scope': 'read write groups', 'created': datetime.datetime(2022, 12, 27, 2, 52, 50, 820066), 'updated': datetime.datetime(2022, 12, 27, 2, 52, 50, 820081), '_id': ObjectId('63aa5e027ef2477a5517c8ac')}}], 'writeConcernErrors': [], 'nInserted': 0, 'nUpserted': 0, 'nMatched': 0, 'nModified': 0, 'nRemoved': 0, 'upserted': []}

Error field is a oauth2_provider_accesstoken.source_refresh_token_id.

First token: source_refresh_token_id = null Second token: source_refresh_token_id = null
But oauth2_provider_accesstoken has a unique index. It name is a source_refresh_token_id.
Therefore, a key error occurs when generating the second token.
And same problem have a oauth2_provider_accesstoken.id_token_id index / oauth2_provider_refreshtoken.access_token_id_1 index.

The solution is to delete the unique index. But I want to avoid deleting.

Is this a bug? Or my mistake? And What is a purpose id_token_id field?

Please, help me.