Changes to auths are needed to get orders - since these are protected only the User who created them.
Server-side flow
Note: This will briefly explain the authentication/authorization flow but We strongly encourage you to use our provided SDKs instead of coding it by yourself since a bug in this process can lead to serious security problems.
If want to use the access token from your server for off-line processing you should implement the server side flow (do not use a client-side-generated token for server side application, see notes below)
In this case the first steps of the flow are the same, but when the user grants the permissions to your application he will be redirected to the url specified when you registered your application with an access_code parameter
User authentication and app authorization are handled at the same time by redirecting the user to our OAuth Dialog. As a result of the authorization, your application receives an authorization code (as opposed to directly delivering an access token).
This authorization code can be exchanged later for an access token and a refresh token.
Overview
If a refresh token is present in the authorization code exchange, then it may be used to obtain new access tokens at any time. This type of access is called offline, since the user does not have to be present at the browser when the application obtains a new access token. The details regarding offline-access permission are explained in the Application Manager guide
When invoking this dialog, you must pass your client id that is generated when you create your application in our Applications Portal (the client_id parameter) and the URL that the user's browser will be redirected to once app authorization is completed (the redirect_uri parameter).
Parameters
response_type: code — Indicates that the desired operation is to obtain an authentication code.
client_id: The client ID assigned to your app when created.
redirect_uri: URL — Optional. The callback URL configured for your app, or one of the allowed domains.
When the user is succesfully logged in a cookie will be stored on the user's computer. If the OAuth dialog is requested for a second time the dialog will not be shown but instead the cookie will be validated. When the dialog is shown the user is prompted to enter his credentials:
Once the user is authenticated succesfully an authorization dialog will be shown in which the user has to confirm that he grants your application the requested data permission. When submitting this dialog the user authenticates your app.
If the user grants your application the requested data permission the OAuth Dialog will redirect the user's browser to the URL you specified in the redirect_url together with an authorization code. This redirect uses the HTTP 302 status code. The URL will look like this:
Using this code you can perform the next step: app authentication. After your application has been authenticated you will receive an access code which you can use when making calls to the API. The authorization code can only be exchanged once for an access token.
The app secret can be viewed when you log in to our Applications Portal, you should never share your application secret with anyone.
To authenticate your app and get a token make a POST to the following URL:
Parameters
grant_type: authorization_code — Indicates that the desired operation is to exchange the code for an access token.
client_id: The client ID assigned to your app when created.
client_secret: hash — The secret generated to your app when created.
code: The authorization code obtain in the first step.
redirect_uri: URL — The callback URL configured for your app, or one of the allowed domains.
If your app is succesfully authenticated and the authorization code from the user is valid, the authorization server will return the access token. An example JSON response is:
Besides the access token, the response also contains the time in seconds the access token expires (the expires_in parameter) and the scope given to the application on the applications creation details.
Refresh your access token (optional)
Access tokens have an expiration time. Typically a webserver application will need to access MercadoLibre APIs at any time. This is called offline_access because the user does not have to be present at the browser when the application obtains a new access token.
How to obtain a refresh token?
After the consumer has been authorized for access, they can obtain a refresh token. The refresh token can be used to get a new access token once it has expired. This is only done after the consumer already has received an access token using either the Web server or user-agent flow.
This becomes necessary when an access token is no longer valid and when you need to make it valid again.
When you register your application in the Applications Portal you need to give offline_access for this purpose.
If you set it up this way, every time your webserver exchanges a code for an access_token it will also receive a refresh token.
Your application will need to save this refresh token along with the access token, as they work in pairs.
Once the access token expires a consumer can use the refresh token to refresh that token and get a new _refreshtoken to refresh it again when it expires.
The consumer should make POST request to the token endpoint, with the following parameters:
Changes to auths are needed to get orders - since these are protected only the User who created them.
Server-side flow
Note: This will briefly explain the authentication/authorization flow but We strongly encourage you to use our provided SDKs instead of coding it by yourself since a bug in this process can lead to serious security problems.
If want to use the access token from your server for off-line processing you should implement the server side flow (do not use a client-side-generated token for server side application, see notes below)
In this case the first steps of the flow are the same, but when the user grants the permissions to your application he will be redirected to the url specified when you registered your application with an access_code parameter
http://your_url?access_code=... Here you must exchange this code for an access token issuing a POST request to… https://api.mercadolibre.com/oauth/token?grant_type=authorization_code&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&code=SECRET_CODE&redirect_uri=$APP_CALLBACK_URL …where you will receive in the response the access token, the expiration time and a refresh token (if you requested offline-access permissions) that you will use to get a new token when the actual token is expired. (all this happens in server side) Server-side flow explained
User authentication and app authorization are handled at the same time by redirecting the user to our OAuth Dialog. As a result of the authorization, your application receives an authorization code (as opposed to directly delivering an access token).
This authorization code can be exchanged later for an access token and a refresh token.
Overview
If a refresh token is present in the authorization code exchange, then it may be used to obtain new access tokens at any time. This type of access is called offline, since the user does not have to be present at the browser when the application obtains a new access token. The details regarding offline-access permission are explained in the Application Manager guide
When invoking this dialog, you must pass your client id that is generated when you create your application in our Applications Portal (the client_id parameter) and the URL that the user's browser will be redirected to once app authorization is completed (the redirect_uri parameter).
Step 1: Obtain a code
Make a GET request to this URL: https://auth.mercadolibre.com.ar/authorization?response_type=code&client_id=Client_id&redirect_uri=REDIRECT_URL
Parameters response_type: code — Indicates that the desired operation is to obtain an authentication code. client_id: The client ID assigned to your app when created. redirect_uri: URL — Optional. The callback URL configured for your app, or one of the allowed domains. When the user is succesfully logged in a cookie will be stored on the user's computer. If the OAuth dialog is requested for a second time the dialog will not be shown but instead the cookie will be validated. When the dialog is shown the user is prompted to enter his credentials:
Once the user is authenticated succesfully an authorization dialog will be shown in which the user has to confirm that he grants your application the requested data permission. When submitting this dialog the user authenticates your app.
If the user grants your application the requested data permission the OAuth Dialog will redirect the user's browser to the URL you specified in the redirect_url together with an authorization code. This redirect uses the HTTP 302 status code. The URL will look like this:
http://YOUR_URL?code=SERVER_GENERATED_AUTHORIZATION_CODE Step 2: Exchange the code for a token
Using this code you can perform the next step: app authentication. After your application has been authenticated you will receive an access code which you can use when making calls to the API. The authorization code can only be exchanged once for an access token.
The app secret can be viewed when you log in to our Applications Portal, you should never share your application secret with anyone.
To authenticate your app and get a token make a POST to the following URL:
Parameters grant_type: authorization_code — Indicates that the desired operation is to exchange the code for an access token. client_id: The client ID assigned to your app when created. client_secret: hash — The secret generated to your app when created. code: The authorization code obtain in the first step. redirect_uri: URL — The callback URL configured for your app, or one of the allowed domains. If your app is succesfully authenticated and the authorization code from the user is valid, the authorization server will return the access token. An example JSON response is:
Besides the access token, the response also contains the time in seconds the access token expires (the expires_in parameter) and the scope given to the application on the applications creation details.
Refresh your access token (optional)
Access tokens have an expiration time. Typically a webserver application will need to access MercadoLibre APIs at any time. This is called offline_access because the user does not have to be present at the browser when the application obtains a new access token.
How to obtain a refresh token?
After the consumer has been authorized for access, they can obtain a refresh token. The refresh token can be used to get a new access token once it has expired. This is only done after the consumer already has received an access token using either the Web server or user-agent flow.
This becomes necessary when an access token is no longer valid and when you need to make it valid again.
When you register your application in the Applications Portal you need to give offline_access for this purpose.
If you set it up this way, every time your webserver exchanges a code for an access_token it will also receive a refresh token.
Your application will need to save this refresh token along with the access token, as they work in pairs.
Once the access token expires a consumer can use the refresh token to refresh that token and get a new _refreshtoken to refresh it again when it expires.
The consumer should make POST request to the token endpoint, with the following parameters:
.... See also ML docs