-
Notifications
You must be signed in to change notification settings - Fork 19
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
OIDC token response to authorization_code grant type should always include an id_token #76
OIDC token response to authorization_code grant type should always include an id_token #76
Conversation
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #76 +/- ##
==========================================
- Coverage 97.87% 94.41% -3.47%
==========================================
Files 15 17 +2
Lines 707 734 +27
Branches 110 114 +4
==========================================
+ Hits 692 693 +1
- Misses 6 32 +26
Partials 9 9
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
I've converted this PR to a draft because I want to update it based on what I've proposed in #75. |
9e5d4ae
to
1314a9b
Compare
1314a9b
to
d897f85
Compare
tests/oidc/core/test_flow.py
Outdated
"authorization_code": AuthorizationCodeGrantType[Request, TStorage], | ||
}, | ||
) | ||
async def test_authorization_code_flow_token_response_includes_id_token( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I should include more of the other authorization code flow tests also?
c9187c9
to
00cda97
Compare
I lean toward handling it in another PR, but I ran into a scenario today where it seems like the |
e98f440
to
872df5b
Compare
872df5b
to
24ec274
Compare
aioauth/oidc/core/grant_type.py
Outdated
) | ||
|
||
# validate_request will have already ensured the request includes a code. | ||
assert request.post.code is not None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these asserts for debugging purposes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The asserts are to make the type checker happy. I've added appropriate if TYPE_CHECKING:
conditions around them to make that more clear.
request.query.code_challenge_method, | ||
request.query.code_challenge, | ||
generate_token(42), | ||
client_id=client.client_id, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of allowing only positional arguments, in which case there will be an explicit indication of what arguments are required:
async def create_authorization_code(
self,
request: TRequest,
*,
client_id: str,
scope: str,
response_type: ResponseType,
redirect_uri: str,
code_challenge_method: Optional[CodeChallengeMethod],
code_challenge: Optional[str],
code: str,
) -> TAuthorizationCode:
it's should not be done in scope of this PR, just as an idea. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm flexible on the matter. I tend to feel like positional arguments can get unwieldy when there is a lot of them and I also like that keyword arguments help someone reading the code outside of an IDE (e.g. in Github for example) to better understand what the purpose of a given argument is without having to go look at the function that is being called to understand what it's positional arguments are.
To that end, I've updated the signature for create_authorization_code
and get_id_token
to include a tail **kwargs
to allow for keyword args to be passed that may be used by a subclass of Storage
. I think this achieves kind of the same thing in that the required arguments are still explicit, but other implementations can take additional arguments as needed.
b01aa7f
to
da3ef5a
Compare
@aliev, sorry for the delay in getting back to your comments. I've made some updates based on your comments and think this PR should be ready for you to take another look whenever it is convenient for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks great! There are a couple of minor changes that can be made within the scope of this PR:
It would be great:
- to include the information about OIDC support to the README.md file: https://github.com/aliev/aioauth/blob/master/README.md?plain=1#L15
- to include instructions on how to enable OIDC support in the documentation: https://github.com/aliev/aioauth/blob/master/docs/source/sections/examples/fastapi.rst
# specifies whether the Authorization Server prompts the End-User for | ||
# reauthentication and consent. The defined values are: none, login, | ||
# consent, select_account. | ||
# https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest | ||
prompt: Optional[str] = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about turning this comment into documentation for the prompt
attribute?
prompt: Optional[str] = None | |
prompt: Optional[str] = None | |
""" | |
Space delimited, case sensitive list of ASCII string values that | |
specifies whether the Authorization Server prompts the End-User for | |
reauthentication and consent. The defined values are: none, login, | |
consent, select_account. | |
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest | |
""" |
@aliev thanks for merging this. Sorry I didn't address your comments; I've had a busy few weeks. I will try to find some time this week to address any comments you haven't already addressed here. |
@tdg5 no worries at all. thank you! |
This creates an OIDC specific version of the
AuthorizationCodeGrantType
that always includes anid_token
. The scope is narrower than I thought previously, and it seems likeid_token
is really only required when getting a token viaauthorization_code
. There are some indications that the password grant type could also include an id token, but so far it seems to vary by vendor.