All specifications for identity federation standards mentioned in this resource guide are freely available online:
OAuth 2 (RFC 6749)
OpenID Connect
Security Assertion Markup Language
These specifications outline multiple, sometimes mutually exclusive, ways to implement federated identity. Therefore, it’s important to read the specifications in their entirety before creating an implementation and to follow community best practices.
Federation standards communities actively track known vulnerabilities in existing standards.
The IETF lists OAuth Security Concerns in in RFC 6819 and hosts a working group to track OAuth standards and vulnerabilities.
The OpenID Foundation lists OpenID Connect security concerns within the specification itself and hosts a working group which actively tracks vulnerabilities.
OASIS has published SAML Privacy and Security Considerations and hosts a mailing list to track SAML vulnerabilities.
Stakeholders need to be aware that selecting an FAL is part of a larger risk- and resource-management process. While it is tempting for stakeholders to request the highest level of security, that is not always in the best interest of the organization. Federated identity projects at higher FALs can be long and complicated, and such complications can take resources away from other work that a security team could be doing that would be of greater benefit to the organization.
Many organizations today operate at FAL1, which is sufficient for most use cases. FAL1 is the industry standard, and there are many libraries and off-the-shelf products that can help an organization implement an FAL1 conformant federated identity system.
Conformance to FAL2 or FAL3 is appropriate for some business cases where there is a risk of fraudulent activity which would be prevented by token encryption, or when the transactions protected by the login is of particularly high value to warrant the additional complexity.