Qodex.ai

Issues technical token to access customer IoT data.

POST {{baseUrl}}/oauth/token?appName=<string>&appVersion=<string>&hostTenant=<string>&userTenant=<string>&caller_context=<string>&caller_context_type=<string>

Returns a technical user access token for the user tenant ID specified in the request body.

The operation can be used by operator and developer tenants. Custom authentication is required, as described in detail at paramter X-SPACE-AUTH-KEY. Instead of X-SPACE-AUTH-KEY header, the Authorization header can also be used.

The request information can be specified as a part of the body or as query parameters. Mixed forms are not allowed - You cannot specify some parameters in the query parameters and the remaining as a part of the request body.

  • When a developer tenant has hosted an app and a token has to be issued for the developer tenant, then the values of 'userTenant' and hostTenant' should both be equal to the developer tenant ID in the request payload or in the query parameters.
  • When an operator tenant has hosted an app and a token has to be issued for the operator tenant, then the values of 'userTenant' and hostTenant' should both be equal to the operator tenant ID in the request payload or in the query parameters.
  • When an operator tenant has hosted an app and provisioned it to another tenant and a token is to be issued for the provisioned tenant, then the value of the 'hostTenant' should be equal to operator tenant ID and the value of 'userTenant' should be equal to the provisioned tenant's ID in the request payload or in the query parameters.
  • In case of impersonated user token, along with appname, appVersion, host and user two more paramaters are required in request body. 'callercontexttype' and 'callercontext'. The value of 'callercontexttype' should be equal to 'email' or 'accesstoken'. The value of 'callercontext' should be a valid user tenant email id or a valid access token based upon callercontext_type.
  • Note : 'callercontexttype' and 'caller_context' are optional paramter to issue technical token to access customer IoT data, but these are required to generate impersonated user token.
  • The 'user-impersonation' feature is made available in Jan 2023.
  • Note : User impersonated token can not be generated for existing app credentials created before Jan 2023. For apps in Developer Cockpit, the app credentials needs to be revoked and regenerated so that User impersonated token feature can be availed on same app version. For apps in Operator Cockpit, new version of app (with app credentials) needs to be created via Developer Cockpit and version upgrade needs to be performed in Operator Cockpit. This app credentials of the upgraded app version will have user impersonated token feature.

Request Params

KeyDatatypeRequiredDescription
appNamestringSpecifies app name for which the token is being fetched.
appVersionstringSpecifies app version of the app for which the token is being fetched.
hostTenantstringThe host tenant is the tenant which deploys and administers the app. Specifies the tenant ID of the host tenant of the app for which the token is being fetched.
userTenantstringThe user tenant is the tenant which consumes the app. Specifies the tenant ID of the user tenant of the app for which the token is being fetched.
caller_contextstringThis is optional parameter, which is required only in case of user impersonation. Specifies the email id of valid user within tenant. A valid combination of caller_context and caller_context_type must be provided to get an user impersonated token. Prerequisite - The email id of user for which token is requested should be present in that tenant.
caller_context_typestringThis is optional parameter, which is required only in case of user impersonation. This is mandatory parameter along with caller_context. Sepcifies the type of context. Accepted values are 'email' or 'access_token'

Request Body

{"appName"=>"<string>", "appVersion"=>"<string>", "hostTenant"=>"<string>", "userTenant"=>"<string>", "caller_context"=>"<email>", "caller_context_type"=>"<string>"}

HEADERS

KeyDatatypeRequiredDescription
X-SPACE-AUTH-KEYstringIs used as authentication information for this operation. The value of this header must be constructed according to basic authentication as
  Basic Base64(&quot;clientID:clientSecret&quot;)

where Base64(.) must be replaced by the Base64 encoded string of its argument string, including the separator colon. For self-hosted applications, clientID and clientSecret are flashed on the screen when registering the application, for Cloud Foundry based applications clientID and clientSecret can be obtained from the environment variables of a MindSphere CloudFoundry application, where the relation from environment variable to client credentials is given by

  MDSP_KEY_STORE_CLIENT_ID     --&gt; clientID
  MDSP_KEY_STORE_CLIENT_SECRET --&gt; clientSecret

<br>Instead of specifying the header name as 'X-SPACE-AUTH-KEY', you can use 'Authorization' header as well. Note that the Authorization header has the same value as X-SPACE-AUTH-KEY. | | Content-Type | string | | | | Accept | string | | |

RESPONSES

status: OK

{&quot;access_token&quot;:&quot;eyJhbGciOi...&quot;,&quot;token_type&quot;:&quot;bearer&quot;,&quot;timestamp&quot;:55969081.88427845,&quot;expires_in&quot;:1799,&quot;scope&quot;:&quot;cst.r uts.su im.usr.r em.rep.r tm.st.r tm.t.r agm.r iam-action.client_credentials.tenant-impersonation uts.ri asm.r atm.r uts.rc uaa.offline_token emds.ent.r asm.rep.r iam-action.client_credentials.user-impersonation mdsp:core:Admin3rdPartyTechUser&quot;,&quot;jti&quot;:&quot;b019ceb63513456c88f2d67c0e92d35b&quot;}