Authenticate as an App

Authenticating as an App involves non-interactive, system-to-system or application-to-application interactions where one application authenticates itself to another service without user interaction. Confidential clients authenticate themselves using the Client Credentials Flow. Because it is the app that is being authenticated, no end user is involved. These apps, running server-side, must be trusted with the client secret.

• A back-end service or daemon authenticates itself to an API. (No user is involved.)
• Common in microservices, background jobs, or server-to-server communication.

• Your app (the client) sends a POST request to the SLB Authenticator's token endpoint with:

  • client_id

  • client_secret

  • grant_type=client_credentials

    Example request

    POST /v2/token HTTP/1.1
      Host: https://csi.slb.com
      Content-Type: application/x-www-form-urlencoded
      Authorization: Basic <base64 encoded CLIENT_ID:CLIENT_SECRET>
      grant_type=client_credentials
      &scope=<CLIENT_IDs>
    
    
    curl --location --request POST 'https://csi.slb.com/v2/token' \\
    --header 'Content-Type: application/x-www-form-urlencoded' \\
    --header 'Authorization: Basic <base64 encoded CLIENT_ID:CLIENT_SECRET>' \\
    --data-urlencode 'grant_type=client_credentials' \\
    --data-urlencode 'scope=<CLIENT_IDs>'

    Request Parameter	Presence	Description
    grant_type	REQUIRED	For Client Credentials Grant, this value must be client_credentials.
    scope	OPTIONAL	If provided, must be a space-delimited list of client_ids of other clients that this client wishes to access with the access_token received from this grant. The "aud" claim in the access_token will contain these client_ids for validation.

• The authorization server validates the credentials.

• If valid, it returns an access token.

  Example Response

  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache
  {
      "access_token":"ACCESS_TOKEN",
      "token_type":"Bearer",
      "expires_in":3600,
      "scope":{
              "valid":["valid clients list"],
              "invalid":["invalid clients list"]
          }
  }

  • The scope field in the response is only returned when the requested scopes contain some non existent or unauthorized client_ids.
  • The scope.valid field contains the authorized and valid scopes that were presented in the request. The valid scopes are also added to the aud claim of the access_token.
  • The scope.invalid field contains the unauthorized or nonexistent scopes that were presented in the request.

• Your app uses this token to call the cloud APIs.

Sample python application (Obtain an Access token for Confidential clients with an ACF grant)