Authorization: Avaya’s Easy Security for Snap-in Developers
Security. Many application developers consider security to be the bane of their existence. We just want to get our features to work, and often don’t want to think about securing those features until the tail end of our development. Unfortunately, cybersecurity is really important in today’s world. Well, I’ve got good news for developers of Snap-inson Avaya Breeze: Avaya has made it easy to securely expose and invoke web services in your Snap-ins.
Security Starts with Authentication—Answering “Who are you?”
Before you allow an application to invoke your features, you need to know the answer to the question “Who are you?” This has often been a difficult question to get answered. There are two major classes of applications, and they each should be authenticated differently.
- Single User Apps: Some applications are directly focused on a single user. These sorts of applications often run on an end user’s device. They might be native applications or web applications running in a browser. For these sorts of applications, you must establish the identity of the end user. Ideally the users can use their enterprise credentials rather than a username and password specific to your application.
- Server-Based Apps: These sorts of applications often operate on the behalf of many users, or don’t have functionality associated with any end users at all. Unfortunately, in the past we’ve often treated server-based applications like users. We give them a bogus username and password. Server-based applications really should be authenticated in a stronger way.
Next, Authorization Answers “Why are you here?”
The user or application successfully proved their identity, what more do we need? Well, we need to know the answer to the question “Why are you here?” and more importantly, “Are you allowed to do what you’re asking to do?”
We’ve usually done a pretty good of authorization for user-focused applications. If I log into a softphone, I can’t pretend to be a colleague as I make crank calls, or check my boss’s voicemail. Server-based applications are a different story. With those, it’s too often been all or nothing. If the application is a trusted super user, it can often do anything it wants. This just doesn’t cut it with the Avaya Breeze™ platform. An application that has been given full access to your snap-in might have no business accessing the services provided by another snap-in, and vice-versa. We need to do better than we have in the past.
OAuth to the Rescue!
Fortunately, Avaya Breeze has drawn upon the industry-standard OAuth 2.0 security framework to help you solve the problems of authentication and authorization. OAuth 2.0 provides a neat separation of concerns so that developers can focus their efforts only where they are required. The Authorization Service is the centerpiece of the OAuth 2.0 architecture. It is responsible for:
- Authentication of users. Multiple forms of authentication can be used, including those that support Multi-Factor Authentication (MFA).
- Authentication of applications. If an application invokes other services, OAuth 2.0 refers to it as a “Client”. This is true regardless of whether the application is running on an end user device or if it is a server-based application.
- Provisioning and tracking of granted scopes. Specific applications can be granted access to specific features / resources.
- Generation of tokens that assert identities and granted scopes.
Some of you will be writing snap-ins with web services that can be invoked by other snap-ins or non-Breeze applications. According to OAuth 2.0 lingo, you’ll be operating as a Resource. Guess what you won’t have to worry about as a Breeze Resource? Authentication! You don’t have to know or care how a user or Client was authenticated. In many cases, you don’t even have to know the identity of the invoker of your service. All you have to care about is whether the user/Client was granted access to your features (scopes). It is completely up to you to say what those scopes are called. If you have a snap-in that interfaces to a coffee dispenser, for example, you might declare a feature called “Make Coffee,” with values of “House” and “Premium.”
Others of you will be writing snap-ins or non-Breeze applications that will invoke other snap-in services. In that case, you’ll be acting as a Client in the OAuth 2.0 terminology. You will need to work with the Avaya Breeze Authorization Service to authenticate your application or snap-in, and optionally to authenticate users of your application. Once you’ve authenticated, you will get a token that you can present when invoking web services. Note that some snap-ins will act both as a Client and as a Resource.
If you read the OAuth 2.0 specification, you might think it seems complex. Fear not fellow snap-in developers, you’ll see in subsequent blogs how our Breeze APIs make it dead simple to securely expose and invoke snap-in web services. For now, if you’d like to learn more, check out the “Authorization” chapter of our Snap-in Development Guide.