The recent \u201cSign in with Apple\u201d vulnerability earned a researcher $100,000 as a part of Apple\u2019s bug bounty program. The flaw itself arose from an OAuth-style implementation that did not properly validate JSON Web Token (JWT) authentication between requests. This would have allowed a malicious actor to \u201cSign in with Apple\u201d using anyone\u2019s Apple ID.The seriousness of the flaw, how simply it was caused, and how easily could have been prevented suggests that you should review the single sign-on (SSO) implementations used by your enterprise systems to see how to better secure them. Single sign-on (SSO) is a centralized approach to authentication and authorization. It improves overall security and user experience (UX) by relieving the end user from repeatedly signing up or signing into a service.Typically, authentication flaws like this one can occur due to lack of a proper security audit of the workflow. Also, when identity management products are procured from vendors without verifying if they strictly conform to industry specifications, blunders like these can occur. These are the safeguards you need to have in place:Perform security audits during SSO procurementAaron Zander, head of IT at HackerOne, notes that since OAuth is an open standard, everyone has responsibility for improving it. \u201cFor the enterprise world, most use tools like Okta, Azure AD SSO, Google\u2019s offerings, or any of the other half dozen or so major vendors that are out there. All are built leveraging OAuth, Security Assertion Markup Language (SAML) or System for Cross-domain Identity Management (SCIM), all of which are open languages that depend on other hardening techniques, like X.509 [encryption] certificates, to stay secure.\u201dEnterprise organizations often don\u2019t focus on the procurement standards enough to ensure tools have SSO and provisioning and de-provisioning, says Zander. \u201cIT and security are often consulted too late in the tool selection process, which usually means choices have already been made, money has been spent, and the tools procured don\u2019t use SSO. The power of single sign-on is based on the fact that the more tools that use it, the stronger you are,\u201d Zander explains.Mandate multi-factor authenticationAs is the case with any password-based authentication system, having a second factor of authentication may not guarantee total security but deters incidents of compromise by a long shot. \u201cOne of the most overlooked and weakest parts of any SSO tool is how people log into it. Too many organizations still rely on passwords that are too short, that get rotated too often, and don\u2019t require MFA for everything,\u201d Zander says.Zander recommends strengthening the weakest links in an SSO workflow, which include policies around password selection and rotation. Users should employ the use of a password manager and update SSO logins with strong passwords (at least 32 characters in length with randomized characters) that need to be rotated less often. He also recommends that organizations use MFA in their SSO implementations.Evaluate architectural placement and protocols in useYour SSO solution may meet industry specifications and be otherwise secure. However, where it resides in your organization\u2019s IT architecture can make a big difference. For example, certain architectural arrangements may mask source IP addresses, posing a challenge.\u201cThe architectural placement of an SSO or OAuth solution in your authentication model is very important,\u201d says Morey Haber, CTO and CISO at BeyondTrust. If you rely on a web proxy, agent-based web content filter, VPN or other tunneling technology, the placement of the SSO solution may mute the actual source IP address of the originating user. This is because tunneling may be required first and the source of all traffic may appear to be coming from the same location first.\u201dMany security strategies rely on automatically blacklisting malicious IP addresses from accessing a system or allowing only a specific IP subnet to connect to one. If you can\u2019t analyze source IPs before traffic is tunneled to the SSO system, it becomes a challenge to limit the system\u2019s exposure to its intended users only.\u201cEnsure the technology is properly placed in your authentication stack so you can see the true source of the user\u2019s IP address in order to provide situational awareness based on geolocation,\u201d suggests Haber.For SAML implementations, peer identification and cryptographic verification can greatly increase confidence in the \u201ctrust based\u201d system. Pascal Geenens, director of threat intelligence at Radware, says, \u201cIn my experience with [SAML], the best advice I can offer for enterprises is to ensure peer identification and validation using certificates, as the entire single sign-on is reliant on the trust between the peers in the system.\u201dPractical advice applicable to your enterprise environment will vary based on what protocols are being used and in what context (locally, over the internet, etc.). The security implications would be different for each type of system, requiring different remediation approaches, given the overall architectural model.Geenens suggest you consider the differences among the technologies. JWT, used by Sign in with Apple, is a specification for JSON Web Tokens that can be used directly by applications or used to build custom authentication or authorization protocols. OAuth and SAML are standardized authentication and authorization protocols. Kerberos SSO, Microsoft SSO and AD\/LDAP are designed to be used inside the enterprise (LAN), whereas SAML and OAuth are built for internet use.\u201dConsider using secure alternativesMuch like there is HTTPS for securing HTTP, FTPS and SFTP (the two are not the same) for FTP, more secure protocols are available for your existing SSO setup. \u201cLDAPS is an LDAP configuration that makes your connection between active directory and other external connections even more secure,\u201d explains Jeff Roscher, president of eWorkOrders. \u201cIt adds an extra layer of protection using TLS with certificates and security keys. At eWorkOrders, we use LDAPS to allow clients to use their own passwords when logging into the CMMS instead of creating, tracking and managing different login credentials for different systems.\u201dSecure LDAP (LDAPS) is a customized \u201cLDAP over TLS\u201d setup and not part of the actual LDAP standard. Therefore, additional verification steps on your end are recommended. Check if the LDAPS library you\u2019re using is correctly implementing SSL with regards to hostname and certificate validations.Limit overall exposure and session validityYour SSO solution might come with a preconfigured session validity and default settings. Review and adjust them with a focus on security. For example, what happens when a user logs into an app via a Facebook account? Should the app be indefinitely authorized via your Facebook credentials, or is there a limit on the validity of this authorization? Asking users to re-authorize services and apps via your SSO system from time to time can greatly help with security, deterring rogue apps with unlimited, unchecked access.\u201cFor transit we recommend using HTTPS, not HTTP, and the SAML assertion encryption to ensure confidentiality,\u201d says Piyush Pandey, CEO at Appsian. \u201cImplementation of the SAML request signature is important to ensure the message integrity as well. Other verifications recommendations are to cross verify the IdP entity ID and the [service provider] entity ID, validate the assertion expiration time, [and to] make sure assertions cannot be reused. Finally, use the \u2018InResponseTo\u2019 validation to prevent replay attacks.\u201dThe validations Pandey recommends, especially around assertion expiration time and responses are critical in preventing replay attacks.Following the above strategies and performing regular security pen testing and audits can greatly assist with stepping up security around your corporate identity management infrastructure.More on SSO:What is single sign-on? How SSO improves security and the user experienceBest tools for single sign-on (SSO)5 best practices to secure single sign-on systemsWhat is SAML? How it works and how it enables single sign onThe perils of single sign-onTurbo-charging your single sign-on solution4 authentication use cases: Which protocol to use?