OAuth 2.0 authorization

OAuth roles

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 a 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 that requests resources from another BMC application.
• Authorization server—The server that authenticates the resource owner, receives the authorization of the client provided by the resource owner, and issues the access token to the client. In the BMC context, it is the BMC Helix SSO server.

OAuth 2.0 flow

OAuth grant types

An authorization grant is a credential representing the resource owner's authorization. The client receives one of the following authorization grants supported by BMC Helix SSO:

Authorization grant	Support by native applications	Support by non-native applications	Description
Authorization code			In this grant type, the application exchanges an authorization code received from the authorization server for an access token.
Refresh token			Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical scope.
JWT assertion			A third-party IdP (Identity Provider) issues a JSON Web Token (JWT), which is signed with a private key. The JWT contains information about an end user on behalf of whom the client wants to access the resources. A certificate signed with the same private key as in the JWT must be configured in the PreAuth IdP on the BMC Helix SSO side. This certificate ensures that there is a trusted relationship between a third-party IdP and BMC Helix SSO. Hence, BMC Helix SSO can generate access and refresh the tokens for clients. To use the JWT assertion grant type, for a realm with PREAUTH authentication type, import the same certificate as the JWT that contains the end-user credentials. The user ID field has to be filled with a value and cannot be left blank even though OAuth automatically uses a claim called sub as the user ID. PREAUTH then validates the signature of the JWT that will be passed to BMC Helix SSO.

OAuth client authentication

BMC Helix SSO enables a client application to authenticate itself with BMC Helix SSO by using the JWT assertion. The JWT contains information about the client application and must be signed with a client secret key (also known as private key) that is shared with the client application during registration. BMC Helix SSO then validates the client application by using the certificate generated by BMC Helix SSO.

Though the client authentication method can be used with any of the grant types provided by OAuth, usage of client authentication with a grant type is not mandatory. A client application can use any of the available authentication methods at any time.

Endpoints for using BMC Helix SSO as an OpenID Connect provider

BMC Helix SSO provides the following OpenID Connect API endpoints:

OpenID scope

OpenID Connect  is a simple identity layer on top of the OAuth 2.0 protocol. OpenID Connect provides the OpenID scope, which can be used with an Authorization code grant type flow. When an OAuth client uses OpenID scope, the Consent page (where an end user allows an OAuth client application to act on behalf of the user) is not displayed to end users.

The following table describes what tokens are returned in the resulting /token call when OpenID scope is used by native and non-native clients: