User's Manual

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.
Client ID and Secret
After you register your app, you will receive a client ID and a client secret. The client ID is considered public
information, and is used to build login URLs, or is included in JavaScript source code on a page. The client secret
must be kept confidential. If a deployed app such as JavaScript or native apps cannot keep the secret
confidential, then the secret is not used.
Redirect URI
During registration of the new OAuth app, often a redirect URI must be included. This redirect URI is used when
a resource owner grants authorization to the client application. When a resource owner has successfully
authorized the client application via the authorization server, the resource owner is redirected back to the client
application, to the redirect URI. It is important to maintain the redirect URI accurately as this forms a key
security mechanism of OAuth2 to whitelist the redirect destination and avoid hi-jacking of the authorization
workflow, as publicized in articles such as http://tetraph.com/covert_redirect/oauth2_openid_covert_
redirect.html.
State
To protect the security of your users by preventing request forgery attacks, the client app should create an
anti-forgery state token. The first step is to create a unique session token that holds state between your app
and the user's client. The app later match this unique session token with the authentication response returned
by the Authorization server to verify that the user is making the request, and not a malicious attacker. These
tokens are often referred to as cross-site request forgery (CSRF) tokens.
Authorization Grant Types for OAuth
OAuth 2 provides several "grant types" for different use cases. W-ClearPass supports the following defined
grant types:
l Password— For logging in with a username and password
l Client credentials— For application access
Resource Owner Password Grant Type
OAuth 2 also provides a password grant type, which can be used to exchange a username and password for an
access token directly. This is often compared with HTTP basic authentication because the same credentials are
being exchanged, but it has the same security benefits as the other OAuth2 grant types in expiring the access
token and the ability to refresh the access token without the need to cache or resubmit the user credentials.
Since this requires the application to natively collect the user's credentials, this grant type should only be used
for apps with a direct relationship (first party) with the authorization server. A real world example would be the
official mobile app for a social networking site versus allowing 3rd party developers to leverage APIs to develop
their own mobile experience for the social platform (they should be leveraging the Implicit flow).
Dell Networking W-ClearPass Guest 6.4 | User Guide Administration | 381