Open deleterepo opened 1 month ago
Thank you for your input, I do first quick feedback round:
I opened a separate issue, with a point of view that we just need to accept PKCE: https://github.com/OWASP/ASVS/issues/1970
Is it already covered by the issue #1826, and if not, what is the difference?
We have #1965 for this opened now.
I think we have requirement 51.2.2 to cover it.
If you have a proposal, how to improve it, please open a separate issue for that.
If you would like to touch the topic from a different angle (as having a new separate requirement), then what could it be?
Is it OIDC specific or is it general JWT validation (https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1)?
V3.5.6 Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience.
For mentioned requirement, we also have a opened issue: https://github.com/OWASP/ASVS/issues/1967
Thank you for your input, I do first quick feedback round:
proposal 1
I opened a separate issue, with a point of view that we just need to accept PKCE: #1970
Sounds good let's continue the discussion in #1970. Please see my latest comments.
proposal 2
Is it already covered by the issue #1826, and if not, what is the difference?
It's covered. Let's keep the discussion going in #1826. Part of these proposals is pointing out what is OIDC-specific, in case we want to have a separate section for that in V51. I also wanted to make sure this issue is still considered as it seems to be an important requirement.
proposal 3
We have #1965 for this opened now.
👍
proposal 4
I think we have requirement 51.2.2 to cover it.
If you have a proposal, how to improve it, please open a separate issue for that.
If you would like to touch the topic from a different angle (as having a new separate requirement), then what could it be?
For 51.2.2 it might be best if I open a separate issue. I think this requirement has too much going on, as it states that we need to only use PKCE (see comments in #1970), and it also talks about using nonce when not using PKCE. PKCE or more specifically Authorization Code flow with PKCE can be used for both OAuth and OIDC, whereas the nonce is specific to OIDC. So the more I think about it the more it makes sense to have a separate section for OIDC, to avoid confusion. One way to start with that is to move or break out any requirements that involve the ID token. What do you think about that?
proposal 5
Is it OIDC specific or is it general JWT validation (https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1)?
V3.5.6 Verify that other, security-sensitive attributes of a stateless token are being verified. For example, in a JWT this may include issuer, subject, and audience.
For mentioned requirement, we also have a opened issue: #1967
This requirement I mention is specific to OpenID Provider Issuer Discovery. See here: https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery. This requirement ensures that the issuer URL used to perform the OpenID Provider configuration request for the configuration document at /.well-known/openid-configuration
, is the same as the issuer URL (claim) in the document itself, and that the same issuer URL is validated against the one in the ID token.
For example, here is one of Google's: https://accounts.google.com/.well-known/openid-configuration?callback=angular.callbacks._0. To perform issuer Discovery, you would make a GET request to retrieve this document, ensuring that the issuer claim matches https://accounts.google.com
. Subsequent ID tokens issued from the token endpoint should have iss
match https://accounts.google.com
as well.
Agree with
If separate issues are opened, we can close this issue.
For requirements - first let's have proposal in the issue, and if it finds agreement, then it's time for PR.
A confidential Implicit Flow grant is fine to use if only the id_token is returned and no access tokens are used/allowed in this flow.
This is sometimes required.
I suggest maybe changing the text in proposal 1 a bit?
A confidential Implicit Flow grant is fine to use if only the id_token is returned and no access tokens are used/allowed in this flow.
This is sometimes required.
I suggest maybe changing the text in proposal 1 a bit?
Hi @damienbod , I understand the comment is on "proposal 1". We have a separate issue for this opened now - https://github.com/OWASP/ASVS/issues/1970
Please share your argument there :)
I politely disagree with the comment below. See https://github.com/OWASP/ASVS/issues/1970#issuecomment-2132789742
A confidential Implicit Flow grant is fine to use if only the id_token is returned and no access tokens are used/allowed in this flow.
This is sometimes required.
I suggest maybe changing the text in proposal 1 a bit?
@elarlang and team I'll begin with a few proposals of my own here to start the discussion about them (more to come). I'll try not to duplicate the ones already mentioned here https://github.com/OWASP/ASVS/issues/1925.
51.1.6
about Resource Owner Password Credentials Grant, but it might make sense to make it a separate requirement to keep it granular, because these grants are vulnerable to different attacks that we are highlighting.Please let me know what you think and happy to discuss these further. More to come!