Obtaining the token

Tip:  If you wish to execute the flow manually, you can use the Postman collection

In order to obtain the SSO token, you need to execute the following flow:

1. Obtaining the client A client is a piece of software that requests tokens from IdentityServer - either for authenticating a user (requesting an identity token) or for accessing a resource (requesting an access token). A client must be first registered with IdentityServer before it can request tokens. Examples for clients are web applications, native mobile or desktop applications, SPAs, server processes, etc.-credentials token
   If your app is registered in DFS.IdentityServer then you should have the token in the context already. If you don’t you can obtain it by calling the ID Server Different literature uses different terms for the same role - you probably also find security token service, identity provider, authorization server, IP-STS, and more. But they are in a nutshell all the same: a piece of software that issues security tokens to clients. IdentityServer has a number of jobs and features - including: a) protect your resources; b) authenticate users using a local account store or via an external identity provider; c) provide session management and single sign-on; d) manage and authenticate clients; e) issue identity and access tokens to clients; f) validate tokens endpoint with the following parameters:
   - Endpoint: POST <ID.Server>/connect/token
   - Request body: application/x-www-form-urlencoded
   

   scope	DfsApi
   grant_type	client_credentials
   client_id	<client-identifier>
   client_secret	<client-secret>
   tenant_uid	<tenant-guid>

2. Obtaining the contact token (intermediate token)
   After obtaining the app token, you can now ask the ID Server for the contact token and define the claims you are interested in by calling the following ID Server endpoint:
   - Endpoint: POST <ID.Server>/connect/token
   - Request body: application/x-www-form-urlencoded
   

   scope	DfsApi
   grant_type	contact
   client_id	<client-identifier>
   client_secret	<client-secret>
   access_token	<access-token retrieved after executing step #1>
   cid	<contact-id>
   sub	<contact-external-id>

   Note:  The cid claim is needed, but if you don’t have the Contact ID in your execution context, you can pass some dummy value there. While the cid may have some dummy value, the sub claim is important (Contact External ID). This value is going to be used in step #3 to validate the contact and generate the final (SSO) token

   Tip:  You can provide other claims (if you need them). For the sake of simplicity, we’ve provided only those two (cid and sub) that are required for the <SL>/v1.0/authenticate/sso endpoint (see step #3).

3. Obtaining the SSO token
   Once you got client app token and intermediate token with contact data (cid and sub claims) you can now generate the SSO token by executing the following SL endpoint:
   - Endpoint: POST <SL>/v1.0/authentication/authenticate/sso
   - Headers: Authorization = Bearer <access-token retrieved after executing step #1>
   - Request body: application/json
   

   Copy

   {
       "AccessToken" : "<access-token retrieved after executing step #2>"
   }