Open TobiasAhnoff opened 2 months ago
OIDC has become industry standard for login, SSO and federation.
Nitpick, introduce the abbreviation on first usage? "OpenID Connect (OIDC) has become industry standard for login, web single sign-on (SSO) and federation."
Maybe precise the intended usage? "OIDC is used for SSO login and might as well be used for single logout-out (SLO)."
Maybe remove "web" in web single sign-on" as it might be used for non web-based native/mobile apps?
Currently the OpenID Connect verifications use the OAuth terminology (client, authorization server). If they are moved in a dedicated chapter, should this be changed to use the OIDC terminology (relying party, OpenID provider) instead? (with some wording explaining the mapping of terminology)
I agree, good to be consistent with terminology from the specs
To define a clear scope for the new OAuth chapter a suggestion si to alos add a OIDC chapter with the following scope definition (where the first section of the chapter i Control Objective and the last is OIDC References). Note that this assumes a new OAuth chapter as well (see #2036) and address (closes) #1924.
Control Objective
OIDC has become industry standard for login, web SSO and federation. OIDC is an identity layer on top of OAuth2 and all verifications in the OAuth2 chapter applies to this chapter as well. This chapter highlights core best current practices for OIDC based on references in the last section of this chapter, while OAuth2 is addressed in the OAuth2 chapter.
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.
This chapter only contains OIDC specific verifications and in example JWT validation and session management is part of other chapters.
OIDC References
OIDC is defined by a large set of specifications, see https://openid.net/developers/specs/. Verifications for this chapter has primarily been aligned with the security profile for Financial grade APIs (FAPI) 2.0, see https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html. FAPI applies to any OAuth2/OIDC application with high security requirements, such as finance, healthcare and government sectors.