-
-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass scope, token and request to OIDC_IDTOKEN_PROCESSING_HOOK #194
Pass scope, token and request to OIDC_IDTOKEN_PROCESSING_HOOK #194
Conversation
The token endpoint handled the scope parameter incorrectly for all of the three handled grant types: 1. For "authorization_code" grant type the scope parameter in the token request should not be respected but the scope should be taken from the authorization code. It was not totally ignored, but rather the scope parameter of the token request was used for the generated ID token. This had two consequences: * Spec conforming implementations of authorization code flow didn't get correct ID tokens, since they usually don't pass scope parameter with the token request. * It's possible to get a broader scope for the ID token than what is authorized by the user in the original authorization code request. 2. For "refresh_token" grant type the scope parameter in the token request should only allow narrowing down the scope. It wasn't narrowed, but rather the original auth code scope was used for the access token and the passed in scope parameter was used for the ID token (again allowing unauthorized scopes in the ID token). 3. For "password" grant type the scope parameter in the token request should be respected. The problem with this was that it wasn't properly splitted when passed to ID token creation. Fixes juanifioren#186
The ID token processing hook might want to add claims to the ID token conditionally based on the scope parameter. Therefore it would be very useful to provide the scope parameter to the processing hook.
I was thinking about this too, to be honest.
For right now I'm thinking about passing |
Having the token as well as the request would be beneficial for me. Right now I'm getting both values through stack inspection :/ |
* '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 (juanifioren#219) Use request.user.is_authenticated as a bool with recent Django (juanifioren#216) Fixed client id retrieval when aud is a list of str. (juanifioren#210) Add owner field to Client (juanifioren#211) Update CHANGELOG removed tab char Add pep8 compliance and checker Bump version Update CHANGELOG.md Preparing v0.5.2 (juanifioren#201) Fix Django 2.0 deprecation warnings (juanifioren#185) Fix infinite login loop if "prompt=login" (juanifioren#198) fixed typos Bump version Fix scope handling of token endpoint (juanifioren#193) Fixes juanifioren#192 Use stored user consent for public clients too (juanifioren#189) Redirect URIs must match exactly. (juanifioren#191) Bug juanifioren#187 prompt handling (juanifioren#188) Don't pin exact versions in install_requires.
6583ee8
to
d804d8a
Compare
14fd133
to
e5b7af2
Compare
@wojtek-fliposports I updated this, as you suggested. Now also the token and the request are passed to the hook function. Also updated the documentation. This should be ready for review now. @juanifioren What do you think? |
The ID token processing hook might need the token or request too, so make them available.
e5b7af2
to
7eb3157
Compare
Great contribution, thanks @suutari-ai. Btw, why the need of passing scope? having |
Hmm.. yes. I thought that it's possible for the requested scope to be different than the token scope for some cases, but now that I recheck the code, it seems that I was wrong there. I checked all create_id_token calls and they all send in a Should I create a PR to remove the scope param from the arguments? |
@juanifioren I created a PR to remove the scope parameter: #245 |
Removing this will prdoce reverse incompatibility
From: Tuomas Suutari <[email protected]>
Reply-To: juanifioren/django-oidc-provider <[email protected]>
Date: Thursday, 31 May 2018 at 08:29
To: juanifioren/django-oidc-provider <[email protected]>
Cc: Wojciech Bartosiak <[email protected]>, Mention <[email protected]>
Subject: Re: [juanifioren/django-oidc-provider] Pass scope, token and request to OIDC_IDTOKEN_PROCESSING_HOOK (#194)
Btw, why the need of passing scope? having token.scope.
Hmm.. yes. I thought that it's possible for the requested scope to be different than the token scope for some cases, but now that I recheck the code, it seems that I was wrong there. I checked all create_id_token calls and they all send in a scope value that is equal to token.scope of the token sent in the same call.
Should I create a PR to remove the scope param from the arguments?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Incompatibility compared to what? Any version of this lib with the scope param was never released AFAIK, so it should be safe to remove it. |
With anyone hwho has been using processing hooks to modify process
From: Tuomas Suutari <[email protected]>
Reply-To: juanifioren/django-oidc-provider <[email protected]>
Date: Thursday, 31 May 2018 at 10:50
To: juanifioren/django-oidc-provider <[email protected]>
Cc: Wojciech Bartosiak <[email protected]>, Mention <[email protected]>
Subject: Re: [juanifioren/django-oidc-provider] Pass scope, token and request to OIDC_IDTOKEN_PROCESSING_HOOK (#194)
Removing this will prdoce reverse incompatibility
Incompatibility compared to what? Any version of this lib with the scope pram was never released AFAIK, so it should be safe to remove it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
and what about using |
@juanifioren The code is already using kwargs when calling the processing hook, so the order of those arguments in the processing hook definition shouldn't matter: https://github.com/juanifioren/django-oidc-provider/blob/develop/oidc_provider/lib/utils/token.py#L65-L67 |
+1 for this
From: Juan Ignacio Fiorentino <[email protected]>
Reply-To: juanifioren/django-oidc-provider <[email protected]>
Date: Thursday, 31 May 2018 at 19:00
To: juanifioren/django-oidc-provider <[email protected]>
Cc: Wojciech Bartosiak <[email protected]>, Mention <[email protected]>
Subject: Re: [juanifioren/django-oidc-provider] Pass scope, token and request to OIDC_IDTOKEN_PROCESSING_HOOK (#194)
and what about using **kwargs instead of positional arguments? @suutari-ai @wojtek-fliposports
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
The ID token processing hook might want to add claims to the ID token conditionally based on the scope, token and/or request parameters. Therefore it would be very useful to provide the scope parameter to the processing hook.
This is a backward incompatible change, but IMHO it's worth it. Updating the client code requires only adding the scope, token and request parameters or
**kwargs
to the hook function . Without this change it requires a nasty hack to get the scope, e.g. something like this:https://github.com/suutari-ai/tunnistamo/blob/bb5bfde43a77373ccc636f458ca696817733f1ae/oidc_apis/id_token.py