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 callback defined via cockpit, adding two parameters,
- code: code with which to get the access_token
- expires: time in seconds that the code is valid
Using code parameter, and the method described in this page the consumer application, can exchange an access token from that code.
|grant_type||The value must be set to authorization_code||string|
|code||the code that is obtained in the authentication process from the your callback URL.||string|
|client_id||Identifier of the client application.||string|
|client_secret||Secret of the client application.||string|
|redirect_uri||Callback URL previously registered via cockpit panel in your app’s settings.||string|
cURL request example
Finally, if everything is ok, the Auth server will respond with the access_token and the following data:
- access_token: token with which to access the user’s private information.
- expires_in: seconds that the access_token takes to expire after it is generated.
- expires_at: date in milliseconds (from 1-1-1970) on which the access_token expires.
- refresh_token: token with which to get a new access_token once it has expired.
- login_status: Login status node of a user.
- uid: internal identifier of the user.
- connect_state: The login state of a user (connected, not connected, unknown).
- scope: (optional), the scope would specify the section to which access is sought.
The possible errors in this step (according to the specification) are: