Authorization, OAuth, OAuth2, OAuth2 Flows

Simplest OAuth Introduction: The Outcome of Years of Dedication to OAuth

October 12, 2018 by oauthio Leave a comment

We live and breathe OAuth so we believe that we can write the simplest OAuth introduction, which is high-level yet technical enough to be useful to investors, managers, and engineers alike. Ready? Strap on for the ride. If we did not do a good job, let us know at the end.

NOTE: Essentially we are talking about OAuth2 even though we use the term OAuth.

 

What is OAuth?

OAuth is a protocol that enables a web service to request permission from a user to perform something on her behalf, often with the goal of making her life more convenient.

For example, a web service that has ‘Login with Facebook’ button is actually requesting that the user grants it permission to read her user profile, so that her profile can be copied over from Facebook to the web service, without her having to key in all those details.

 

How is OAuth different from other authorization protocol?

Most authorization protocol takes a centralized approach; as a server implementing the protocol, you decide on the who (partners, developers, etc.) can perform an action, and what action (permission scope, e.g., read profile, download file, etc.) can be performed.

OAuth, on the other hand, implements delegated authorization; each user on the OAuth provider is delegated the authority to decide who can perform an action on her behalf and what action can be performed.

 

Who are the parties involved in OAuth?

There are 3 parties involved:

  • Web service – wants to perform something on behalf of the user, e.g., read her profile
  • OAuth provider – where the user has an account, e.g., Facebook, and only the OAuth provider knows how to authenticate her, i.e., verify who she claims she is, e.g., through username/password, two-factor authentication (2FA), biometrics, etc.
  • User – wants to use the web service and willing to grant permission to the web service to communicate with her account on the OAuth provider, e.g., permit the web service to read her profile on the OAuth provider

 

How does OAuth flow?

There are 4 different OAuth flows, each for a specific use-case, which we will not cover here.

However, all 4 of them share the same 2-step high-level flow:

1. The web service, user, and OAuth provider interact, and it results in the web service acquiring a digital access token embedding the user’s identity (authentication) and permissions (authorization)

User, OAuth Provider, Web Service interact to bestow access token embedded with user identity and permission to the Web Service

2. The web service presents the digital access token, to any service that trusts the OAuth provider, so that the service performs the permitted action on behalf of the user

Web Service presents the access token to APIs to gain access

For all 4 OAuth flows, part 2 is identical. However, the way the web service, user and OAuth provider interact in part 1 to bestow the digital access token to the web service is different, which we will not cover here, but you can see comparison flow diagram here.

 

When do I need OAuth?

You can use OAuth as a consumer, provider, or federated entity.

We already talked about using OAuth as a consumer, here is a recap; you are a web service that wants to access some user data residing another service or perform something on behalf of the user on another service, and the service implements access control using OAuth, which requires the user to grant you permission in the form of a digital access token.

As a provider, you are a web service that has a lot of users and data, and you want to increase the value of your platform by empowering developers all over the world to create applications for your users by utilizing their data through API endpoints, so you need to implement delegated authorization access control on those API endpoints using OAuth protocol.

As a federated entity, you want to implement Single-Sign On (SSO) where authentication is done only once by the centralized OAuth provider, with the outcome being a digital token comprising user identity and permissions, which can be presented to any set of services trusting the OAuth provider in order to gain access.

 

Conclusion

You can now articulate OAuth like a pro! If not, we would like to hear from you where we fell short in this introduction.

If you want to do not want to deal with OAuth complexity and prefer to effortlessly consume OAuth as a web service, become an OAuth provider as a platform, or use OAuth for Single-Sign On (SSO) please chat or email with the experts at OAuth.io or schedule a call.