PKCE (often pronounced “pixie”) and the Authorization Code grant. Originally intended to enhance OAuth security for mobile applications, this combination provides extra security benefits to all clients using this updated protocol.
It is important to understand OAuth is not an authentication protocol. It’s an authorization protocol.
OAuth 2.0 was intentionally designed to provide authorization without providing user identity and authentication, as those problems have very different security considerations that don’t necessarily overlap with those of an authorization protocol. — OAuth.com
Authentication is about proving you are you. Authorization is about delegating access or permissions to information.
Historically, OAuth has been used as both a way of dealing with both authentication and authorization. However, OAuth doesn’t define a standard way to provide user information to the requester—so every auth implementation is a little bit different. This removes some of the benefits of using a standardized protocol.
Many developers may also assume that obtaining an access token from a third-party service means that your user was authenticated. But that’s not true. An access token could be granted to your application even if your user was not authenticated (that’s 100% up to the service you are requesting access to).
Authentication features like getting identity information, session management, and user registration have to be handled some other way. OAuth servers often support OIDC, which we’ll cover below.
If you are creating an app that needs to get information from another source, then OAuth makes sense. It helps to limit your app’s access to your customer’s resources, and it facilitates the process of requesting and obtaining permission.
While often misunderstood as an authentication protocol, OAuth is not a standardized solution for authentication, as mentioned above. Let’s look at some proper authentication protocols that you can use to authenticate your user.
You’ve seen that OAuth is a great way to gain access to resources. But it doesn’t define a standard way to authenticate your user. OpenID Connect (OIDC) solves authentication by extending the OAuth 2.0 protocol, what is technically called a “profile” of OAuth.
OIDC adds an “Id token” to be returned from the final OAuth request in the flow. This confirms the user was in fact authenticated (unlike the access token, as discussed previously) and also gives you a way to access identity-specific information about the current user.
Beyond these basic features, OIDC can also enable more advanced features such as session management, log-out ability, user registration standard, and more.
OIDC is a great choice when you want to allow your users to log into your applications via another service, such as Google, Facebook, Twitter, or other social providers.
Historically, this was done using OAuth along with some customized extras. OIDC provides a solid standard for doing this in a secure and trusted manner.
As mentioned above, OIDC is very often supported by OAuth servers. If you have an OAuth server, check to see if it supports OIDC (FusionAuth does).
SAML stands for “Security Assertion Markup Language.” It’s an SSO (single sign-on) standard that is XML-based. It typically enables business users to sign into their organization’s authentication system and automatically log in to the external and third-party applications their employer allows.
SSO offers immense convenience for users. It’s also secure in that businesses can have more control over their user’s security by enforcing policies such as strong passwords and two-factor authentication. These policies then apply, by proxy, to all their external applications.
While transparent to the user, when they access a configured third-party service, it will issue a request to an authentication system called an “identity provider.” If the user is already logged into their organizational identity provider, then it will send a special response to the external application to tell it, “This person is authenticated; let them in!”
SAML is a great tool for larger organizations to further enhance their users’ security. Again, the organization can have full control over a user’s authentication policies and force any configured third-party applications and services to “use” the organization’s authentication system to verify users. For organizations that are seeking compliance with security programs such as ISO 27001 or SOC 2, SSO is often necessary.
FIDO stands for “Fast Identity Online.” It’s a set of protocols created by the FIDO Alliance, a nonprofit group seeking to expunge the use of passwords. In general, the FIDO protocols allow users to authenticate themselves via special devices or applications that use fingerprint readers, facial recognition, or external devices such as special USB dongles. Many websites are also now supporting WebAuthn, which is a protocol that enables website logins with FIDO.
FIDO works much like SSH keys. Your device will have a FIDO-enabled “authenticator” application that can generate private and public keys between your device and other services. Your device keeps a private key for that service and sends it a public key. Whenever the device reads your fingerprint, for example, the device’s authenticator application will verify you are you and then use public key cryptography to authenticate you to that other service.
This means that attackers can’t steal your password. It’s also much more convenient than having to enter a password over and over again.
FIDO is a great choice for larger organizations that want to keep their users and devices very secure. If an organization chooses to use some type of specialized hardware, such as a Yubico device, that can be a substantial cost. Not only must the devices be purchased, but they must be delivered when employees are onboarded and retrieved when they leave, incurring additional logistical complexity.
However, with growing support for WebAuthn and built-in facial recognition and fingerprint readers on modern PCs, many cloud-based tools are allowing FIDO-based authentication for their websites, lowering the overall cost of using FIDO. Thanks to FIDO’s strong security, you’ll often see FIDO used in government, insurance, and healthcare.
You’ve seen that using a standard authentication protocol is important. It can make sure you are implementing authentication in a trusted and reliable way. Using tools like SSO/SAML can allow your organization to enforce more secure policies that apply across many external applications your organization’s users require to do their jobs.
Even better, by using an auth system such as FusionAuth, you don’t even need to implement all of these protocols. You can use FusionAuth to manage your user authentication and it comes with support for OAuth, SAML, and OIDC out of the box.
Whatever tools you choose to use, your understanding of when and why OAuth, OIDC, SAML, and FIDO are appropriate can help you choose the best authentication standard for your organization’s goals, security posture, finances, and future growth.