Rate this page

Client Authentication

As explained previously, the Data Governance Broker grants access tokens through two endpoints, the authorization endpoint and the token endpoint. The purpose of the authorization endpoint is to authenticate an end user and to authorize a client’s OAuth 2 or OpenID Connect request. The token endpoint issues access tokens to clients, and clients authenticate to it using HTTP basic authentication.

HTTP Basic Authentication

HTTP basic authentication, described by RFC 7235 and RFC 2617, is used by clients making requests to the Data Governance Broker’s token endpoint. This is a simple authentication scheme in which a client provides a set of encoded credentials as a value of the Authorization request header. To construct the basic authentication value, the client joins an identifier and a secret with the : (colon) character, base64-encodes this value, then prepends it with the string Basic (including a space character).

The general form is: Basic <base64-encoded <client ID:client secret>>

For example, given the client ID “Client1” and the client secret “secret-password”, the client takes the string Client1:secret-password and base64-encodes it, yielding the string Q2xpZW50MTpzZWNyZXQtcGFzc3dvcmQK. The full authorization header value is then Basic Q2xpZW50MTpzZWNyZXQtcGFzc3dvcmQK. A token endpoint request using these client credentials might look like the following:

POST /oauth/token HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Authorization: Basic Q2xpZW50MTpzZWNyZXQtcGFzc3dvcmQK
Connection: keep-alive
Content-Length: 239
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Host: example.com:443

grant_type=authorization_code&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback%2F&code=AXxINZiqwlLFWkS0_kG78XJRoTxyAAAAAAAAAADiQ8A5ZaEhAODxditL8vQr6TUl3PkR-SKRFiLcF-fesEZLnBmArwT-V9BE7HqqLIp9goZPGrgOUPSzJOwynOPmZAV8lAKjcpCiwkGsn-EAYQ

This authentication type requires that credentials are encoded but not encrypted. To protect credentials from attackers, therefore, HTTPS must always be used.

HTTP Bearer Token Authentication

HTTP bearer token authentication, described by RFC 6750, is used by clients when making requests to the Data Governance Broker’s UserInfo and SCIM services.

As with basic authentication, the Authorization request header is used. In this case, though, the client must provide an access token, which is prepended with the string Bearer (including a space character).

The following example shows a UserInfo request with bearer token authentication:

GET /userinfo HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Authorization: Bearer eyJraWQiOi...
Connection: keep-alive
Content-Type: application/json; charset=utf-8
Host: example.com:443

As with basic authentication, credentials are not encrypted, and HTTPS must always be used to protect the access token from interception by attackers.