In order to protect themselves in a growing attack landscape, companies must employ defensive security techniques and evaluate if they’re doing enough to prevent bad actors from accessing their networks. In this post, we’ll discuss types of authentication that allow companies to verify access of both users and devices at the network edge.
Before we explore the options, we have to consider the context. Authenticating users and devices are wildly different based on capabilities and use cases. Authentication into an application will likely require a username and password or federated authentication with an identity provider for single sign on (SSO). Alternatively, authenticating a device doesn’t involve a user and is limited to the context and information the device has at runtime.
For traditional user-based authentication, HTTP basic authentication — also known as basic auth — allows teams to protect access to services with one or more username and password combinations. This is the simplest approach for adding authentication to a service but has the drawback of a limited number of usernames and passwords. This makes HTTP basic auth implementations less secure. Because of that limitation, it’s unsuitable for any real production use cases.
As a system grows in capability and importance, authentication and authorization requirements grow too. For robust requirements, teams can leverage an identity provider (IdP) to use OAuth 2.0 or OpenID Connect (OIDC), which are both JWT-based, to extend inbound federation to protect their system.
If you’ve integrated third-party applications with data sources like Facebook or phone directories you've likely utilized OAuth 2.0. This authentication protocol facilitates secure delegated access, allowing applications to perform operations on servers without direct user credentials. Instead, the identity provider (IdP) issues tokens to these third-party applications, contingent upon user authorization. A cornerstone in modern API-driven ecosystems, OAuth 2.0 is crucial for maintaining security while granting scoped access.
OpenID Connect (OIDC) represents an identity layer atop the OAuth 2.0 protocol. Its primary function is to enable third-party applications to validate the end-user's identity and access fundamental user profile data. OIDC employs JSON web tokens (JWTs), acquired through OAuth 2.0 compliant flows. This protocol delineates a versatile suite for facilitating client-end-user identity interactions, empowering various clients to inquire and retrieve data about authenticated sessions and end-users. Additionally, it facilitates backend API access utilizing OAuth 2.0 tokens.
Within the SaaS domain, OIDC stands as a predominant authentication protocol. Its vast acceptance can be attributed to its innate adaptability with both web and mobile platforms.
Many enterprises use Security Assertion Markup Language (SAML), which is an open standard for exchanging authentication and authorization data between an IdP and a service provider. It enables SSO by authenticating a user once and communicating the authentication to multiple web applications. It’s considered very user-friendly because users can log in to multiple services with a single set of login credentials.
Mutual TLS (mTLS) works by having two entities at opposite ends of the network. These can be services, devices or users, which each have their own certificate. As the entities negotiate the connection, they exchange certificates to prove their own identities and create a temporary trust relationship. This ensures that only known and expected entities can connect to protected services.
Webhook verification is usually two tightly connected components. First, there’s verifying the sender and verifying the payload or content. Authentication addresses the first aspect. Most of the major webhook providers — Stripe, Twilio, Okta, Shopify, etc. — implement a verification method to ensure that incoming requests are from trusted systems via a shared secret or certificate, a payload signed by a secret key or both. While not truly authentication, sometimes webhook vendors may publish IP ranges for their webhooks. These aspects work together to better protect the applications consuming webhooks.
In between user and device authentication is API authentication. At times, an API must authenticate and act on a user’s behalf. This is common when a user grants an application access to read and update their account on another system like Google, Facebook or similar. In each of those cases, the app is acting as the user. On the other hand, we have devices that interact with an API independent of any user at all. In both cases, a simple username and password combination is a common solution. The more secure option, however, is OAuth. Not only does it protect a user’s credentials but it also moves both scenarios to a common, repeatable set of patterns.
SAML 2.0 is most frequently used by large organizations to authenticate their employees to services. The organizations will manage the identity of the users and also what they are authorized to access. OAuth or OIDC may be used in certain cases.
Most consumer facing application owners will be focused on making end user sign in as frictionless as possible. At scale, a consumer application may use a Customer Identity and Access Management solution like Auth0, PingIdentity, OneLogin, etc. These solutions will offer SAML, OAuth, and OIDC options to authenticate users.
The single most important part of all of these authentication capabilities — HTTP basic authorization, OAuth, OIDC, SAML and mutual TLS — is that they are applied at the edge before the traffic reaches a network, server or device. This eliminates unauthorized traffic, reduces the attack surface and mitigates lateral attacks — before it even hits your infrastructure — without modifying a service.
To learn more about adding authentication at the network edge without disrupting user workflows, visit our docs and the ngrok blog.
