Configuring OAuth 2.0
This topic provides information about OAuth 2.0. It contains the following topics:
OAuth 2.0 is an authorization framework for third-party applications. On behalf of a resource owner, third-party applications use OAuth 2.0 to get limited access to an HTTP service. The framework also enables an approval interaction of the resource owner with HTTP service. In addition, OAuth 2.0 supports directs access to the HTTP services by the third-party application.
The following roles are supported by OAuth 2.0:
- Resource Owner—The end user who grants access to protected resources.
- Resource Server—The server that hosts the protected resources and allows access by receiving an access token from the third party application. In the BMC context, it is a BMC application.
- Client—The third-party application that requests access to protected resources on behalf of the resource owner. The client can also be a BMC application which requests resources from another BMC application.
- Authorization server—The server that authenticates the resource owner, receives the authorization of the client by the resource owner, and issues the access token to the client. In the BMC context, it is the Remedy Single Sign-On (Remedy SSO) server.
The following image represents the OAuth protocol flow.
The OAuth 2.0 protocol performs the following process for authorization:
- The client, for example a third party application requests authorization from the resource owner to access a BMC application. A consent page is displayed for the resource owner to grant access to the third party application. Authentication of the resource owner happens using one of the existing authentication methods.
- The client receives an authorization grant, which is a credential representing the resource owner's authorization.
- The client requests an access token by authenticating with the authorization server and presenting the authorization grant. Registering of the client details with the authorization server is a prerequisite for issuing an access token.
- The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token. Access tokens have a shorter validity period. The authorization server issues refresh tokens when the client has additional requests.
- The client requests the protected resource from the resource server and authenticates by presenting the access token. The client uses REST APIs to access the resources. The REST APIs need to be registered with the client.
- The resource server validates the access token, and if valid, serves the request.
To configure OAuth2
- Enter the OAuth2 details.
For more information on parameters, see OAuth2 parameters.
- In the Clients tab, click Register. The client tab is used to register a client and view the list of all registered clients.
- Click Save.
|Access Token Timeout|
|Refresh Token Timeout||
Sets a timeout for the refresh token. After expiration, the issued access token is no longer valid.
Access and refresh tokens remain valid until their expiration. To avoid security concerns, access tokens must be of a short duration. Refresh tokens typically have a longer validity, but cannot be used without providing a valid client id and secret.
Registers the client identifier issued to the client by Remedy SSO server during the registration process. This information is prepopulated.
Registers the client name specified during the registration process. This could be any name of the administrator's own choice.
|Redirect URI||Registers URI to which the authorization code is sent after /authorize request succeeds. This URI must be properly handled on the client's side.|
|Enabled||Allows the client for authorization.|
|Action||Enables to edit or delete a record.|
|Search and view the list of tokens and refresh the necessary token(s).|