In the increasing time of online networking, user authentication remains a big challenge for all users but adds another level of concern for enterprises. Corporations want to validate whether people are who they say they are and whether they are allowed to do what they are trying to do.
Authentication protocols provide the security of sending authenticated data (username, password, tokens etc.) over networks between an identity provider (IdP) and different service providers (relying party applications).
The blog discusses what authentication protocols are, the common ones used in enterprises these days and the differences between them.
What are Authentication Protocols?
Authentication protocols are a set of instructions which are used to communicate authenticated data between two entities.
Authentication protocols are used to authenticate users for two types of access:
Centralized Authentication (Single Sign-On)
In centralized authentication, a user is given a single login credential (username, password, token etc.) to access multiple applications/services within the same enterprise.
This is usually termed as single sign-on (SSO), an approach to maintaining a centralized database which provides single identity for every user in the organization.
For example, you log in to your Gmail account, and that provides you access to you Google Drive, YouTube etc., without having to actually provide login credentials at every other Google-related application.
Federated Authentication (Federated Identity)
In federated authentication, a user uses its credentials to access multiple applications/services across different enterprises.
This is usually termed as federated identity management (FIM), where multiple domains have a trust relationship that allows users to be authenticated across IT infrastructure.
For example, you can use your Google account to login to other websites.
Among some of the well-known authentication protocols used today are OpenID Connect and SAML-P. These protocols take the data/credentials entered by the user and validates them against the credentials managed by the user’s identity provider (IdP).
Security Assertion Markup Language (SAML) is an XML-based open-standard that provides authentication between an IdP and a service provider. It is one of the major authentication protocols used today and one of the first to be used for federated access, giving it a large foothold in the SSO domain.
OpenID Connect (OIDC) is an authentication protocol, which introduces an identity layer on top of the authorization framework: OAuth 2.0. In in a way, it is an extension of OAuth 2.0. OIDC is a fully developed protocol for both authentication and authorization, making heavy use of JSON security tokens (JSON web token) to communicate user attributes between the service provider and the IdP.
Let’s look at what both these authentication protocols offer, and which one is better for your business authentication needs.
OIDC vs. SAML: Comparing key authentication protocols
Both the protocols achieve the same thing but the way they authenticate users differs in method, technology and capacity.
- Message Format: In OIDC, we have JSON Web Token (JWT) called id-token which provides the authentication information. On the other hand, in SAML, we have assertions which represent the authentication, attribute and authorization statements and are formatted using XML. JWTs are light-weight as compared to heavy XML assertions.
- Support for API: OIDC came out of necessity that SAML is too heavy and can’t integrate well with APIs. OIDC works by using RESTful API communication that utilizes the HTTP communication channel to send light-weight JSON security tokens for the authentication process, whereas SAML uses SOAP, which is also a protocol layer over HTTP, but it sends heavy XML messages for user authentication.
- Mobile-centric Authentication: As mentioned above, OIDC uses RESTful communication to create lightweight JSON security tokens that are passed between IdP and relying party, this makes OIDC a forefront protocol for mobile centric application authentication, unlike SAML which was mainly developed to be used for web application authentication, and because it uses XML there is no future space for it to be used in mobile applications, giving an edge to OIDC being used exclusively in mobile applications.
- User Consent: Because OIDC is a layer placed upon the OAuth framework, OpenID Connect can provide a built-in layer of authorization, which prompts a user to first consent to what the service provider can access. Even though SAML can provide consent flow, it does this through hard-coding done by the developer, instead of having it as a standard in its protocol.
- Static Authentication: In SAML, static authentication is required where the IdP and the relying party must be configured to know each other before the actual transfer of information takes place. While for OIDC, it is not the case.
Both authentication protocols are extremely powerful and advantageous. The application of each protocol depends on what the enterprise is trying to achieve. If they require authentication that is lightweight, highly interoperable with APIs and mobile applications, then they could choose to implement OIDC rather than SAML, whereas a company would choose SAML because it is a more mature protocol as it has been around quite longer and has been the standard for a lot of established enterprises.
The choice of using an authentication protocol for your business really boils down to what you are trying to incorporate into your business and authentication needs. Fortunately, VIDIZMO offers both options to its users while implementing enterprise video content management system in your organization’s IT infrastructure.
To learn basics of single-sign on authentication, refer to our blog Single Sign-On: What It Is, Why You Need It, and How We Do It. To explore the specifics of VIDIZMO SSO, read 5 Things You Should Know About VIDIZMO Single Sign-On.