Description

It lets you determine whether a logged-in user has enough data defined in a section. It comprises 2 parts:

  • Check if data need to be completed.
  • If they need to be completed, show the user an appropriate interface.

This flow is handled using 2 calls to 2 methods.

Step 1: Check if data need to be completed

To check if a user needs to complete the data for a specific section, a call has to be made to the DRUID API with the following data:

Endpoint URL:

 GET https://{your-endpoint-domain.com}/user/api

Request parameters

ParameterDescriptionType
w.sectionThe entry point about which you want to ask.string
fFor this case, this parameter must be set to UserMeta string
sFor this case, this parameter must be set to needsToCompleteData string
oauth_token access_token of the logged userstring

Request example

Response

AttributeDescription
userBelongsTypologyUser belongs to scope typology
needsToCompleteOptionalDataUser does not have some optional field filled, so you can redirect user to complete_account to allow fill it
needsToConfirmIdsUser have pending id confirmation (eg: email, mobile..) so you can redirect user to complete_account to allow confirm it
needsToCompleteDataUser does not have some mandatory field filled, so you can redirect user to complete_account to allow fill it
needsToAcceptConsentsThe user has some non mandatory consent to false, so you can eventually redirect user to the data completion to allow you to set it to true if he/she wish.
needsToAcceptTermsUser must accept some t&c . After login. The user will be required to accept them if he/she wants to continue.

Step 2: Redirect to complete account

If some data  need to be completed, the user has to be asked to complete them.

The authorization sequence is started by redirecting the browser (all of the page) to a DRUID URL with a set of configuration parameters that tell the server what type of access to the DRUID resource servers your application requires. As in other scenarios, DRUID takes care of user authentication, creating the shared session in all domains and consent to access to the data requested by your application.

In this particular case, the user must be authenticated on the server or a logged-in user access token must be provided.

Endpoint URL:

 GET https://{your-endpoint-domain.com}/oauth2/authorize
ParameterDescriptionType
client_id identifies the appstring
redirect_uriURL to which the OAuth server will redirect the user’s browser after completing the authentication process by the users. These URLs have to be registered in the cockpit panel.string
response_typeThe value must be set to none.string
x_methodPossible values could be ‘complete_account”, to redirect user to desired flow.string
stateAllows you to restore the previous state of your application. The state parameter preserves some state objects set by the client in the Authorization request and makes it available to the client in the response (eg: session identifier, json info base64 encoded…). The content must be url urlencoded.string
scopeScope is a mechanism in OAuth 2.0 to limit an application’s access to a user’s account. In the case of DruID, you must send the id of the entrypoint you want to use for the desired flow.string

Response

The server checks that the input parameters are correct, and if found to be logged in, redirects the user to the next step. If the user is not logged in, the user is redirected to the login screen.

When the user completes the actions on the displayed screen, the OAuth server responds to the browser control to the app via GET to the URL it received in the redirect_uri parameter.

Error codes

The possible errors in this step are:

  • invalid_request
  • invalid_client
  • unauthorized_client
  • redirect_uri_mismatch
  • unsupported_response_type
  • invalid_scope