It seems like there are multi ways to achieve that, all of them highliting
the importance of maintain a single source of truth for the version number.
More info: https://packaging.python.org/guides/single-sourcing-package-version/.
This PR includes one possible approach, open to discussion.
It seems like many lead institutions related with security are
recommending a minimum key length of 112-bits since 2013.
In order to achieve that, a RSA key size of 2048 (or more) is required.
To make it easier to change the AuthorizeEndpoint and Client we set them as class variables. Then people inheriting from the view are able to easily change them. In my personal case this helps with skipping consent more explicitly as defined in issue https://github.com/juanifioren/django-oidc-provider/issues/278
Have the option to use the more readable response type value rather than
the ResponseType id integer in fixtures and dumpdata output.
Prior to this change dumpdata represents response types like so:
"response_types": [2]
And after this change when using `dumpdata --natural-foreign`:
"response_types": [["code"]]
The Dynamic Client Registration spec specifies multiple response_types
and grant_types per client
(https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata).
Since grant_types can be inferred from response_types we should be able
to support both without needing to store grant_types.
This also helps with oidc-client-js which expects a client that supports
both "id_token" and "id_token token".
We ran into a client that blindly takes the value of token_type, which
is lowercase "bearer", and passes that back in the Authorization header.
In an earlier PR #99 there seemed to be some support for this change to
simply accept "bearer" in addition to "Bearer".
Django 1.11 deprecated the django.contrib.auth.views.logout
function-based view, which django-oidc-provider relied on. This
patchset instead subclasses the new LogoutView.
LogoutView was introduced in Django 1.11. logout() was deprecated in
1.11 and removed in 2.1. Accordingly, this patch adds Django 2.1 to
CI and removes 1.8, 1.9, and 1.10.
Resolves#258
The response can simply omit fields that require id_token as the only
required field is "active" according to RFC 7662. I think it would be
nice for introspection of client credentials tokens to be supported by
default without needing to override
OIDC_INTROSPECTION_VALIDATE_AUDIENCE_SCOPE, but this is a start.
Based on the OAuth 2.0 Token Introspection spec the "aud" field should
be based on the token. Previously "aud" was populated with the id of the
client making the introspection request which seems wrong. This changes
the endpoint to return the value from the token.
The "client_id" field is then changed to return the client id for the
client that originally requested the token rather than returning the
"aud" value from the token.
From the spec https://tools.ietf.org/html/rfc7662:
client_id
OPTIONAL. Client identifier for the OAuth 2.0 client that
requested this token.
aud
OPTIONAL. Service-specific string identifier or list of string
identifiers representing the intended audience for this token, as
defined in JWT [RFC7519].
Up until recently there were settings with truthy defaults but with no
need to be set to a false value. That changed with
OIDC_INTROSPECTION_VALIDATE_AUDIENCE_SCOPE. Now there is a setting that
has both a true default and a meaningful false value, and without this
fix that setting cannot be changed making it not much of a setting at
all.
* 'develop' of github.com:juanifioren/django-oidc-provider:
Update changelog.rst
include request in password grant authenticate call
Update setup.py
Update changelog.rst
Update changelog.rst
Adjust import order and method order in introspection tests
Replace resource with client in docs.
Update settings docs to add extra introspection setting
Update README.md
Update README.md
Remove the Resource model
Skip csrf protection on introspection endpoint
Add token introspection endpoint to satisfy https://tools.ietf.org/html/rfc7662
Test docs with tox.
Remove Django 1.7 for travis.
Drop support for Django 1.7.
Move extract_client_auth to oauth2 utils.
Remove duplicate link in docs.
Bump version v0.6.0.
Fix BaseCodeTokenModel and user attr.
Update README.md
Edit README and contribute doc.
Edit changelog.
Update changelog.rst
Add protected_resource_view test using client_credentials.
Fix docs.
Improve docs.
Client credentials implementation.
Move changelog into docs.
Update README.md
Update CHANGELOG.md
Fixed infinite callback loop in check-session iframe
Fix PEP8. New migration.
Update example project.
Fix PEP8.
Fix PEP8.
PEP8 errors and urls.
PEP8 models.
Fix contribute docs.
Fix tox for checking PEP8 all files.
Update README.md
Update README.md
Simplify test suit.
Update CHANGELOG.md
Bump version 0.5.3.
Update installation.rst
Update CHANGELOG.md
Fixed wrong Object in Template
Update project to support Django 2.0
Now passing along the token to create_id_token function.
Made token and token_refresh endpoint return requested claims.
Sphinx documentation fixes (#219)
Use request.user.is_authenticated as a bool with recent Django (#216)
Fixed client id retrieval when aud is a list of str. (#210)
Add owner field to Client (#211)
Update CHANGELOG
removed tab char
Add pep8 compliance and checker
Bump version
Update CHANGELOG.md
Preparing v0.5.2 (#201)
Fix Django 2.0 deprecation warnings (#185)
Fix infinite login loop if "prompt=login" (#198)
fixed typos
Bump version
Fix scope handling of token endpoint (#193)
Fixes#192
Use stored user consent for public clients too (#189)
Redirect URIs must match exactly. (#191)
Bug #187 prompt handling (#188)
Don't pin exact versions in install_requires.
An an example this can be used to help implement measures against brute
force attacks and to alert on or mitigate other untrusted authentication
attempts.
This commit fixes the JS callback defined in the check-session iframe which can produce infinite callback loops if the received message doesn't come from the relying
party. In that case another message is posted to the source of the message (which can be the OP itself) thus resulting in an infinite loop because "error" messages are
continuously generated by the callback function.
