Open Authorization, commonly known as OAuth, is a standard protocol that provides applications with the capacity for "secure designated access".  

Through OAuth, applications can access resources on behalf of a user, without the need to share user credentials unlike other authentication methods like OTP SMS by OTP service providers.

Understanding OAuth in Simple Terms

To understand OAuth in simpler terms, imagine a scenario where you want to allow a third-party website, like ESPN, to access your Facebook profile or post updates on your timeline. Ordinarily, you would need to provide ESPN with your Facebook password.  

But with OAuth, ESPN can access your profile without you having to share your password. This drastically minimizes the risk of your password being exposed in the event of a security breach on ESPN's end.

Here is an example of a world without OAuth:-

A Closer Look at OAuth

OAuth is essentially an authorization protocol, not an authentication protocol. It provides authorization tokens to prove an identity between consumers and service providers. OAuth facilitates one application to interact with another on your behalf, without having to share your password.

The Evolution of OAuth

OAuth was released as an open standard in 2010, under the RFC 5849, and it quickly gained widespread adoption. Two years later, it underwent significant revision, and OAuth 2.0 was released in 2012 as RFC 6749. Despite criticisms, OAuth 2.0 saw even more widespread use, with major companies like Amazon, Facebook, Instagram, LinkedIn, Microsoft, Netflix, and PayPal joining the list of adopters.

The Inner Workings of OAuth

OAuth operates on the principle of roles, which are fundamental components of an OAuth system. These roles include:

1. Resource Owner: This is the user or system that owns the protected resources and can grant access to these resources. ‍
2. Client: This is the system that needs access to the protected resources. To access these resources, the Client must possess the appropriate Access Token. ‍
3. Authorization Server: This server handles requests from the Client for Access Tokens and issues them upon successful authentication and consent by the Resource Owner. ‍
4. Resource Server: This server protects the user’s resources and receives access requests from the Client. It accepts and validates an Access Token from the Client and then returns the appropriate resources.

The Concept of Scopes in OAuth

Scopes are an integral part of OAuth. They are used to specify the reason for which access to resources may be granted. The acceptable scope values and the resources they relate to are dependent on the Resource Server.

OAuth 2.0 Access Tokens and Authorization Code

In OAuth 2.0, the Authorization server may return an Authorization Code instead of directly returning an Access Token after the Resource Owner has authorized access.  

This code is then exchanged for an Access Token. For added security, the Authorization server may also issue a Refresh Token with the Access Token.

How Does OAuth Work?

At the most basic level, before OAuth 2.0 can be used, the Client must acquire its own credentials, a client id, and client secret, from the Authorization Server. This is to identify and authenticate itself when requesting an Access Token.

OAuth vs. OpenID

OAuth and OpenID are often interchanged, but they serve different purposes. While OAuth is about authorization, OpenID is about authentication. OpenID verifies the identity of the user, while OAuth provides secure, third-party, user-agent, delegated authorization.

OAuth vs. SAML

Security Assertion Markup Language (SAML) is another technology often compared with OAuth. SAML describes a framework that allows one computer to perform both authentication and authorization on behalf of one or more other computers. OAuth, on the other hand, requires an additional layer like OpenID Connect to perform authentication.

OAuth 2.0

OAuth 2.0 is a complete redesign from OAuth 1.0, with the two versions being incompatible. OAuth 2.0 is faster and easier to implement. It provides six flows for different types of applications and requirements and allows for signed secrets over HTTPS.

Is OAuth Safe?

Whilst OAuth is widely accepted and used, it's not without vulnerabilities. One of the major criticisms of OAuth 2.0 is that the standard intentionally does not directly define or support encryption, signature, client verification, or channel binding.  

It relies on implementers to use an outside protection protocol like Transport Layer Security (TLS) to provide those features.

Some alternatives to OAuth are OTP SMS and other methods like those which are deemed as the future of authentication.

Conclusion

Despite its limitations, OAuth has been a game-changer in facilitating seamless access across multiple applications using a single set of credentials. It has paved the way for secure, third-party, user-agent, delegated authorization, making it easier for users to interact with multiple web applications. As the digital landscape continues to evolve, OAuth will undoubtedly continue to play a pivotal role in how we access and interact with web applications.