saleram1 / sim-jquery

m2m the ML to Magento Store Connect - Integration
1 stars 0 forks source link

As [System] Need to Store Both accessToken and refreshToken Objects in DB for each User #19

Open saleram1 opened 12 years ago

saleram1 commented 12 years ago

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:

    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

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:

    {
       "access_token" : "APP_USR-6092-3246532-cb45c82853f6e620bb0deda096b128d3-8035443",
       "token_type" : "bearer",
       "expires_in" : 10800,
       "scope" : "write read"
    }

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.

    {
       "access_token" : "APP_USR-6092-3246532-cb45c82853f6e620bb0deda096b128d3-8035443",
       "token_type" : "bearer",
       "expires_in" : 10800,
       "refresh_token" : "TG-1025633383c1a2f67323423423b05213abb",
       "scope" : "write read offline_access"
    }

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

saleram1 commented 12 years ago

This is to capture orders and other protected objects.