aaronpk
commented
3 years ago I‘m fine with pointing out to readers that omission of response type „token“ does not deprecate other extension response types.
Best place to add this is probably https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-03#section-6.4
Thanks as lot Vittorio! You gave us a lot of homework but I think the draft will be improved a lot based on it.
Re OIDC implicit: I‘m reluctant to explicitly endorse use of OIDC implicit (response type „id_token“ or „code id_token“) as there are examples in the wild where the id_token is used as access token. Moreover, I‘m not aware of any systematic security threat analysis of those flows.
I‘m fine with pointing out to readers that omission of response type „token“ does not deprecate other extension response types.
WDYT?
Thank you, I am so glad you think so!
I hear you on the id_token abuse. That would be easily solved by appending a “provided that the resulting id_token is not abused by using it as access token”, in fact that would explicitly address one of the most common abuses we witness in this space by finally providing explicit language on the matter. I had frequent clashes with the Kubernetes crowd about it, and they required nuanced arguments, making them grok the concept of audience etc etc- all stuff that could have been avoided by having straightforward language along the lines of the above. We could argue whether that language belongs to the OIDC spec more than the OAuth2.1: my position is that we should take this opportunity to bring extra clarity, nothing prevents repeating that if the OIDC people will do their own updates in the future. I also hear you on the open endorsement, however I suspect that just saying what you suggest without mentioning OIDC at all will not solve the problem of people thinking this deprecates those OIDC flows, too. Perhaps a compromise would make it explicit that the security considerations that led to the omission of implicit for the token response type in oauth2.1 do not apply to those flows in OIDC, provided that the id_token is not used as access token. So non an endorsement, but an explicit scoping statement 😊 would that sound more balanced?