V51 OAuth: Add new OIDC Authorization Server verifications
TobiasAhnoff opened this issue · 11 comments
The following verifications are suggested to be added to the proposed new OIDC chapter (see #2037).
Authorization Server
Verify that well known industry standard Authorization Servers are used, preferably these services are certified and listed at https://openid.net/certification/#OPENID-OP-P. For L3 applications they should also be implement the FAPI security profile.
Verify that only the grant types 'code', 'ciba' or 'id-token' are used. Note that FAPI 2.0 recommends 'code' over the OIDC Hybrid flow 'id-token code' (which was previously recommended in FAPI 1.0).
Verify that all clients requiring access tokens are using the 'code' grant or, if needed for device flows, the 'ciba' grant.
Verify that only the grant types 'code', 'ciba' or 'id-token' are used. Note that FAPI 2.0 recommends 'code' over the OIDC Hybrid flow 'id-token code' (which was previously recommended in FAPI 1.0).
I believe the wording is somewhat misleading: there is no grant_type=id_token but response_mode=id_token / code id_token.
Verify that well known industry standard Authorization Servers are used, preferably these services are certified and listed at https://openid.net/certification/#OPENID-OP-P. For L3 applications they should also be implement the FAPI security profile.
For me it feels that we have it covered with dependency requirements in V14.2 Dependency. I think ASVS should concentrate on vulnerabilities not on certificates, although there can be correlation.
Verify that only the grant types 'code', 'ciba' or 'id-token' are used. Note that FAPI 2.0 recommends 'code' over the OIDC Hybrid flow 'id-token code' (which was previously recommended in FAPI 1.0).
Is the wording updated based on feedback?
Verify that all clients requiring access tokens are using the 'code' grant or, if needed for device flows, the 'ciba' grant.
todo: is it covered somewhere else?
Verify that only the grant types 'code', 'ciba' or 'id-token' are used. Note that FAPI 2.0 recommends 'code' over the OIDC Hybrid flow 'id-token code' (which was previously recommended in FAPI 1.0).
and
Verify that all clients requiring access tokens are using the 'code' grant or, if needed for device flows, the 'ciba' grant.
both overlaps with #2043 which has
Verify that for a given client, the authorization server only allows the usage of grants that this client actually needs to use. Note that the grants 'token' (Implicit flow) and 'password' (Resource Owner Password Credentials flow) should no longer be used.
But this address OAuth, not OIDC, and I think it is good to keep OIDC details separated, perhaps rewrite the two suggested OIDC requirements as one, like this
Verify that the OIDC Implicit flow is not used by any Relying Party. The OpenID Provider should only allow respone-modes 'code', 'ciba', 'id-token' or 'id-token code'. Note that 'code' should be preferred over 'id-token code' (the OIDC Hybrid flow), while 'token' (any Implicit flow) should not be used.
Verify that well known industry standard Authorization Servers are used, preferably these services are certified and listed at https://openid.net/certification/#OPENID-OP-P. For L3 applications they should also be implement the FAPI security profile.
For me it feels that we have it covered with dependency requirements in V14.2 Dependency. I think ASVS should concentrate on vulnerabilities not on certificates, although there can be correlation.
I agree that ASVS should not mandate certifications, the vulnerability I aim to address with this is that some of the most broken OAuth and OIDC implementations are the ones that are custom built, not following the specs.
I don´t think V14.2 currently captures this clearly, however 1.2.3 actually address this by stating
Verify that the application uses a single vetted user authentication mechanism that is known to be secure
Perhaps that is enough to mitigate the risks with custom built flows and OAuth/OIDC token services?
Maybe instead of having this as a requirement, add a note on the importance of using "well known industry standard Authorization Servers/OpenID Providers and flows" to the OAuth/OIDC chapter text? (without referring to the OIDC certification)
Verify that the OIDC Implicit flow is not used by any Relying Party. The OpenID Provider should only allow respone-modes 'code', 'ciba', 'id-token' or 'id-token code'. Note that 'code' should be preferred over 'id-token code' (the OIDC Hybrid flow), while 'token' (any Implicit flow) should not be used.
Some things to work on:
- It is written as a "negative" requirement
- is "should" here recommendation or requirement?
Maybe instead of having this as a requirement, add a note on the importance of using "well known industry standard Authorization Servers/OpenID Providers and flows" to the OAuth/OIDC chapter text? (without referring to the OIDC certification)
It can be mentioned in the chapter text, but in general, I would not say that "don't write your own", as our focus must be that whatever is written, must follow the requirements. Often those "well-known" products have their own weaknesses.
It can be mentioned in the chapter text, but in general, I would not say that "don't write your own", as our focus must be that whatever is written, must follow the requirements. Often those "well-known" products have their own weaknesses.
1.2.3 is probably enough to capture this, if a note to clarify what this means for OAuth/OIDC is needed, it can be added later (when the new OIDC/OAuth chapter is more finished).
Is this better?
Verify that the OpenID Provider only allow respone-modes 'code', 'ciba', 'id-token' or 'id-token code'. Note that 'code' is preferred over 'id-token code' (the OIDC Hybrid flow), while 'token' (any Implicit flow) should not be used.
Updated proposal:
Verify that the OpenID Provider only allows values 'code', 'ciba', 'id-token', or 'id-token code' for response mode. Note that 'code' is preferred over 'id-token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) should not be used.
The section?
I suggest OIDC OpenID Provider or, if there will be only two or three OIDC requirements, perhaps only have a OIDC section?
Added via #2122
V51.5 OIDC OpenID Provider
| # | Description | L1 | L2 | L3 |
|---|---|---|---|---|
| 51.6.1 | [ADDED] Verify that the OpenID Provider only allows values 'code', 'ciba', 'id-token', or 'id-token code' for response mode. Note that 'code' is preferred over 'id-token code' (the OIDC Hybrid flow), and 'token' (any Implicit flow) should not be used. | ✓ | ✓ | ✓ |
Note that we are going to delete 1.2.3 (as duplicate of 1.2.4), #1181
@elarlang thanks for noting that! Using "secure token services" is of course critical for secure OIDC/OAuth implementations, but, as noted in #1181 (comment), this is hard to express in a requirement or two...regardless of outcome from #1181, I think it is good to keep generic things like that in chapter 1 and not have requirements in the OIDC/OAuth chapter for "secure token services".
Given that, it is clear for the reader of the OAuth/OIDC chapter that the requirements are in addition to most other chapters in ASVS. In example with a note like this in the beginning of the chapter (copy from V13 API and Web Service)
Please read this chapter in combination with all other chapters at this same level; we do not duplicate authentication, authorization, session management, general input validation concerns and so on. Rather, the general requirements from other chapters always apply and therefore this chapter can not be taken out of context and be tested separately.
So, with that, I think all 3 initially suggested requirements have been addressed.