SSO, OAuth, Secrets Management

Understanding Secrets Management, OAuth, and Single Sign-On (SSO)

Once upon a time, access management was a simple thing. It focused mostly on making sure that the right users had the right passwords to the right systems.

Over the past decade or so, however, access management has grown into a much more complex discipline. It’s no longer just about managing passwords for individual systems. Today, access management encompasses a range of sub-disciplines, including secrets management, single sign-on (SSO), and password-less authorization techniques like OAuth.

Understanding the art and science of access management for modern IT environments requires mastering all of these sub-disciplines. Toward that end, this article provides an overview of secrets management, SSO, and 0Auth, explaining what they have in common and what makes them different.

What is secrets management?

Secrets management refers to tools and processes that allow organizations to manage the “secrets” that are used for encrypting and decrypting data, or for authenticating users, applications, and services with each other.

In this context, secrets mean not just passwords, but also access keys (for services like SSH), encryption keys for data, and API tokens that are used to authenticate application services.

Modern secrets management is founded upon a few core principles:

  • All secrets should be able to be stored and managed from a central location in order to prevent so-called “secrets sprawl.”
  • Secrets management tools and processes should support all types of secrets, not just passwords. This is why password managers or key-management services are not enough on their own to fulfill secrets management requirements.
  • Secrets should be able to be shared automatically if desired. In other words, your secrets manager shouldn’t require a human admin to log in and access a secret; it should be configured to share secrets automatically when desired. That way, applications can authenticate and authorize requests automatically.

What is SSO?

Single sign-on, or SSO, means exactly what it sounds like: The ability for a user to be granted an authorization one time, and then access more than one system.

You’re probably already familiar with SSO principles due to your experience as an everyday Internet user. For example, chances are that when you log into your Web-based email account, you are also logged into the calendar, contacts manager, and other software that is part of the productivity suite you use.

SSO offers several benefits, including:

  • User-friendliness: Users don’t have to enter passwords every time they open a new application. They may also have fewer passwords to remember.
  • Fewer support requests: Fewer passwords and sign-ons means fewer requests for support from users who run into access problems.
  • Fewer secrets to maintain: By allowing users to configure just one set of credentials for multiple services, SSO can reduce the number of secrets that an organization needs to maintain for its users.
  • Encourages stronger passwords: When you require your users to create and remember fewer passwords, you increase the chances that they will follow password best practices by creating one strong password, instead of creating weaker passwords that they find easier to remember.

What is OAuth?

OAuth is an open authorization protocol that helps enable SSO. Introduced in 2010, OAuth provides a shared protocol that different applications can use to enable SSO for their users. In other words, developers can write applications in such a way that an OAuth-based authorization into one application enables authorization in the other application too — even if the two applications are otherwise separate from each other and share no resources in common.

It’s certainly possible to implement SSO without using OAuth, but OAuth makes it easier. Despite various criticisms of OAuth security over the years, OAuth has emerged as the most widely used solution for enabling SSO between different Web services and applications.

Secrets management vs. SSO and OAuth

In short, then, secrets management on the one hand, and SSO and OAuth on the other, serve fundamentally different purposes. Secrets management allows organizations to keep track of all of the information that they need for securely authenticating and authorizing requests to IT resources. SSO and OAuth, on the other hand, support a particular authorization technique oriented around allowing users to authenticate only one time.

Secrets management, SSO, and OAuth all support the broader goal of achieving secure, scalable, user-friendly access management. A good secrets manager, like Conjur, will help to store and manage all of the secrets that enable authentication and authorization processes, whether they are part of an OAuth-based SSO process or something else.

Join the Conversation on the CyberArk Commons

If you’re interested in this and other open source content, join the conversation on the CyberArk Commons Community. Secretless Broker, Conjur, and other open source projects are a part of the CyberArk Commons Community, an open community dedicated to developers, engineers, cybersecurity researchers and other technically minded people. To discuss Kubernetes, Secretless Broker, Conjur, CyberArk Threat Research and related topics, join us on the CyberArk Commons discussion forum.