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.
The result of the previous sequence is an authorization code. After receiving the authorization code, your application must exchange this code for an access token (access_token) and an update token.
For more information, please read the Auth flow
Your app must make a redirection to the server in order to let a user authenticate with login or register screen. All the codes and values of each parameter must be UTF-8-encoded and URL-encoded.
The result of the request, if they are not logged in, would be a redirection to the login page, which will appear in the user’s browser. If they are logged in and have authorized access to your application, it would redirect directly to the next step.
Supposing that the user was correctly authenticated (they entered a valid username and password), The Auth server will inform the Client (consumer application) by sending a GET request to the redirection URI, taking back the control of the browser to your app.
|client_id||identifies the app that is calling the login or register window||string|
|redirect_uri||URL 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_type||The value must be set to code. This is the type of response that you want to get if the authentication process was resolved satisfactorily. It returns a code with which to get the access token||string|
|x_method||This parameter is optional.|
Possible values could be ‘sign_up’, ‘login’,’reauthorize’, to redirect user to desired flow.
If not send, default value will be ‘login’.
If you call this endpoint with x_method=reauthorize, you will be able to force logged user to go to login page and fill user credentials again.
Your access and refresh tokens will be invalidated, so user is still logged in DruID (using SSO) but user is not logged in your app.
If user does not fill credentials and click on ‘back button’, will realize that are not logged in (and force to fill credentials as requested)
Therefore you should not use SSO if you want this process to work as spected.
The server checks that the entry parameters are correct, and after that it redirects the user browser with an authentication screen so that the user can enter their email and password (or any other authentication credential) to prove they are who they say they are.
Once the user is correctly authenticated, the OAuth server responds to the control of the browser to the app by GET to the URL that received in redirect_uri parameter.
The possible errors in this step are: