Authentication, Authorization, and Interoperability

The SaaS ecosystem relies on several solutions and protocols for authentication, authorization, and the exchange of information with other systems (interoperability). 

In this post, we will review the protocols and solutions, that enable data exchange between SaaS applications for Identity and Access management. The communication between the applications provides a seamless experience out of the box that is scalable and repeatable.

Solutions: 

  • Identity Providers (IdP) - User information database that is used to authenticate/ validate user identity. Common IdPs are Google, Microsoft, Facebook, Apple, etc.
  • Single Sign On (SSO) - An Authentication solution that allows users to access multiple SaaS applications with one set of credentials. Examples for SSO - Okta, PingID.
  • Multi-Factor Authentication (MFA) - MFA is used to verify the identity of a user when trying to access an application. Standard MFA methods are SMS text with a code, Google/ Okta authenticator, Hardware token, Facial recognition etc. 

Protocols:

  • OAuth- an open standard for access delegation commonly used to grant websites or applications access to user information in order to gain access to other applications.
    OAuth is commonly used when performing a social login (i.e. User Consent). 
  • SAML- SaaS applications use SAML protocol to exchange messages with IdPs/SSOs to authenticate users.
    One of the key differences between SAML and OAuth is that OAuth supports the exchange of permissions. For example, when a user signs up to Pinterest using Google Workspace, a user can consent  to provide Pinterest with permissions to access user's Google Workspace environment (i.e. Extension). Continuous monitoring of such Extensions is crucial and we cover all aspects of it in the Extensions Module review blog post.
  • The messages exchanged include properties about the user (stored in the IdP/SSO) called attributes. Default attributes are the full name and email address of the user.
  • Non-default attributes are called custom attributes and configured by the IdP/SSO administrator. Some SaaS applications require Non- default attributes and, therefore, will be included.  

1

Comments

0 comments

Please sign in to leave a comment.

Didn't find what you were looking for?

New post