The most well-known authentication and authorization frameworks and standards in identity and access management (IAM) are OAuth, OpenID Connect (OIDC), and SAML (Security Assertion Markup Language).
The primary difference between these standards is that OAuth, now known as OAuth 2.0, is an authorization framework used to protect specific resources, such as applications or sets of files, while SAML and OIDC are authentication standards used to create secure sign-on experiences.
SAML (Security Assertion Markup Language) is an open federation standard that enables single sign-on (SSO). It's the oldest standard of the three and most commonly used by enterprise organizations to allow their users to access web-based applications and services that they pay for. Salesforce and Gmail are examples of applications that employees access after successfully completing a SAML sign-on.
SAML is an XML-based framework, which means it's extremely flexible, can be used on any platform, and can be transmitted by a variety of protocols including HTTP and SMTP. Authentication information is exchanged between identity providers and service providers to verify the user’s identity and permissions, and then grant or deny their access to the applications.
Widely used in enterprise organizations, SAML was created to support SSO for browser-based applications and services. It does not support SSO for mobile applications or applications that access resources through the API.
OAuth, now known as OAuth 2.0, is an open standard framework for API authorization. It’s important to note that OAuth is an authorization protocol and not an authentication protocol, but information about the user can be used for authorization purposes. It defines how an API client can obtain security tokens that contain a set of permissions against the resources available through that API.
Instead of requiring a user to share login credentials with one application to give that application access to another, OAuth delegates authorization decisions to a separate authorization server that hosts the user account. Essentially, OAuth acts on behalf of the user, providing delegated access to a third-party service without the user exposing their credentials to that third party.
Perhaps the most important thing to understand is that OAuth is not an authentication protocol. For example, OAuth doesn’t define a specific token format or a common set of scopes for the access token. Nor does it address how a protected resource validates an access token.
OAuth also supports service-to-service and device-to-service use cases, and SAML does not.
The OpenID Connect (OIDC) protocol adds an authentication and identity layer to OAuth 2.0 and is one of the newest security protocols available. Like OAuth, it delegates user authentication to the service provider that hosts the user account and authorizes third-party applications to access the user’s account. But OIDC also provides access to mobile applications, APIs, and browser-based applications.
Each time users sign on to an application or service using OIDC, they are redirected to their OpenID provider, where they authenticate and are then redirected back to the application or service.
Use OIDC in situations where:
You’re building a new application from scratch. Especially if you want your application available from mobile devices.
You want to define what a user can do within an application after they have been authenticated.
JWTs will serve you better than XML.
Start Today
See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.
Request a FREE Demo