Administrator Guide

OAuth 2.0 is a simple and secure authorization framework. It allows applications to acquire an access token for
W-ClearPass through a variety of workflows supported within the OAuth2 specification. After an application
has an access token, it can access the various APIs serviced by W-ClearPass either to configure the platform
itself or act on behalf of a W-ClearPass Operator. To use OAuth for authorization:
l Decide on the use case for API Access Either W-ClearPass administrative configuration, or managing
W-ClearPass data on behalf of a W-ClearPass Operator (Guest Management, Onboarded devices, Device
Registration etc).
l Create a W-ClearPass API Client definition that matches the use case above Either Service Account (client
credentials) or Authorized User Account (resource owner password), respectively.
l Request an Access Token using the Client ID details from the W-ClearPass API client definition created in the
previous step.
l Make authorized API calls to the W-ClearPass APIs by including the Bearer <access_token> in the HTTP
Authorization header.
OAuth Basics
The best way to understand the different use cases for OAuth2 is to start with the various roles that make up a
possible OAuth2 transaction.
Resource Owner
The resource owner is the person or application that owns the data that is to be shared. For example, a user on
Facebook or Twitter could be a resource owner, in the same way as an Operator on W-ClearPass. The resource
they own is their data. Typically the resource owner is thought of as a person but it could also be an
application. The OAuth 2.0 specification supports different workflows for each of these use cases.
Resource Server
The resource server is the server hosting the resources. For example, either a platform such as Facebook or a
W-ClearPass Server could be considered a resource server. It is essentially the server hosting the protected
content that will be accessed via the APIs.
Client Application
The client application is the application requesting access to the protected resources stored on the resource
server.
Authorization Server
The authorization server authorizes the client application to access the resources of the resource owner. The
authorization server and the resource server can be deployed as part of the same server, but the OAuth 2.0
specification does not dictate whether they should be co-located or separated. For simplicity, the rest of this
document assumes the resource server and authorization server are co-located on the same server.
OAuth2 Client or App
Before any OAuth transactions can be processed, the first step is to register a new app with the service (API
Client definition in W-ClearPass). When you register a new app with the Authorization Server, you specify basic
information such as the application name and the OAuth2 grant type. Depending on the grant type selected, a
redirect URI may also be requested in order to whitelist the redirect destination for OAuth2 workflows that are
initiated from Web server, browser-based, or mobile apps.
The output of registering an OAuth2 app is a client id and client secret.
Dell Networking W-ClearPass Guest 6.5.0 | User Guide Administration | 461