A little about OAuth

July 30, 2019

Tweet This:
Share on LinkedIn:

By Kevin Prater, Kovarus, Practice Manager Collaboration / Network Edge

By Kevin Prater, Kovarus, Practice Manager Collaboration / Network Edge

I’ve recently done a little work with OAuth to support a Cisco UC environment and as always learned a bit here and there. Yes, I know it’s been around for a while, but I thought maybe an introduction to the standard and some things I picked up may be useful for someone out there. For this primer, we’ll keep it simple though and start with the basics:

  • What is it?
  • How does it work?
  • Why would you even care?

What is OAuth

Open Authorization (OAuth) is an authorization protocol that enables applications limited access to services on other 3rd-party resources requiring authentication and authorization. Whew, what? Let’s pick that apart.

OAuth deals with authorization and since we need to know who you are before we authorize you to do anything it’s important to draw the distinction between authentication and authorization.


Authentication is the process or action of verifying the identity of a user. This might be as simple as a user name and password, maybe a certificate, or any other thing that proves you are who you say you are and with multi-factor these days, you may need to provide even more proof. All we’re concerned with here though is validating that you are you. It is not defining what you can do or what you can access; that’s authorization.


Authorization is the process of defining access rights or privileges to an entity, like a user, application, or service. This details what an authenticated party can do, where they can do it and for how long. Keep that last part in mind. Once you’re authorized, you are free to access whatever you’ve been granted access to…until the timer runs out; then you’ll need to be re-authenticated.

Once you’re authenticated, you gain access to the 3rd-party resource via an OAuth authorization token generated by the OAuth service.

You see OAuth in action all the time. You want to authorize a 3rd-party web app access to information on your social media account and there’s a button that says “Login with Facebook” or something like that. Pressing that button takes you to your social media site where you log in with your user name and password. Your social media site authenticates you and allows an access token to be issued to that application via OAuth. Violà! Without ever supplying any personal credentials to this 3rd party, you’re authorized access to protected resources. The benefits to this approach being:

  • Increased security
    • Better auth control
      • Define what access they have
      • Define a time limit on access
    • User credentials are kept secret between the trusted site/app and the user
  • Better user experience
    • Reduction in password support tickets
      • Authentication doesn’t fail when password changes
    • Faster subsequent logins once authenticated
    • No need to re-authenticate if client is started

How do you do that thing you do

OAuth (RFC 6749) is a framework specification and within it contains several authorization functions. To understand how the authorization flows work we need to define the roles OAuth uses in the authorization process.

OAuth roles
    • Resource Owner — This is the end user who authorizes an app to access their account.
    • Client — This is the application that wants access to the end user’s account. The application must be authorized by the end user and the authorization must be validated by the Authorization Server.
    • Resource Server — This is the server that hosts the protected end-user accounts.
    • Authorization Server — This is the OAuth server. It verifies the user’s identity and issues OAuth access tokens to the application.

A simple walkthrough of the authorization process might look like this:

  • An application sends a request to access resources
  • The end user authorizes this request and an authorization grant is returned
  • The application then sends a request for access along with the auth grant to the authorization server
  • The application’s identity is authenticated so the OAuth Server issues an access token to the application
  • The application now requests access from the resource server and instead of credentials (it doesn’t have them) it presents the access token for authentication
  • The access token is good so the resource server allows access to the requested resources

Why would you even care?

In my case I was working with OAuth to support the Cisco Jabber Client. In this particular environment Jabber would be accessing several different services from the Cisco Collab infrastructure; things like IM & presence, call control and voicemail, so the end user would need to be authenticated against several different servers.

We all know that a great collaboration environment stems from a great user experience and having to supply multiple credentials within the client for multiple servers (services) is not only clunky from a security perspective but is a bit cumbersome for end users and ends up being an administrative headache. So, enable OAuth. Provide your users with “Solution Level Authentication” as opposed to hitting every single application within the environment.

Have questions? Let’s talk! Hit me up on Webex Teams at kprater@kovarus.com

Don’t have an account? That’s OK too, creating a Teams account is free! Download the Desktop App and get started here: https://www.Webex.com/downloads

Looking to learn more about modernizing and automating IT? We created the Kovarus Proven Solutions Center (KPSC) to let you see what’s possible and learn how we can help you succeed. To learn more about the KPSC go to the KPSC page.

Also, follow Kovarus on LinkedIn for technology updates from our experts along with updates on Kovarus news and events.