At Decathlon, we value the integrity and security of our members' data above all else.  In order for your applications to access Decathlon member data and/or act on their behalf, they must be Authenticated.  To make this process as easy as possible, Decathlon relies on the industry standard OAuth 2.0 protocol for granting access. 

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.

The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner.

Configuring your application

If you have not already done so, request for your application creation.

To prevent fraudulent transactions during the authentication process, we will only communicate with URLs that you have identified as trusted endpoints.
Ensure the "OAuth 2.0 Redirect URLs" field for your application contains a valid callback URL to your server that is listening to complete your portion of the authentication workflow.

Once created, your application will be assigned a unique Client ID and Client Secret value.

Request an Authorization Code

It's time to request an authorization code. 
The authorization code is not the final token that you use to make calls to Decathlon with. 
It is used in the next step of the OAuth 2.0 flow to exchange for an actual access token. 

Redirecting the User

To request an authorization code, you must direct the user's browser to Decathlon Login's OAuth 2.0 authorization endpoint.

• If the user has not previously accepted the application's permission request, or the grant has expired or been manually revoked by the user, the browser will be redirected to Decathlon Login's authorization screen.
• If there is a valid existing permission grant from the user, the authorization screen is by-passed

Parameters :

https://api-global.decathlon.net/connect/oauth/authorize?client_id=a97za22a-1320-41f6-9aad-ee3118654fbe&redirect_uri=https%3A%2F%2Fblablabla.com&response_type=code&scope=profile%20sports
                                            

Application is approved

If the user was not logged in, Decathlon Login will ask him for a login and a password.
If it the first time he use your application OR if you asked for a new scope access, he will have to approve your application's request to access datas.
This approval instructs Decathlon Login to redirect the user back to your redirect_uri parameter.

Attached to the redirect_uri will be two important URL arguments that you need to read from the request:

• code — The OAuth 2.0 authorization code.
• state — A value used to test for possible CSRF attacks. Should be the same you entred in your request

The code is a value that you will exchange with Decathlon Login for an actual OAuth 2.0 access token in the next step of the process.
For security reasons, the authorization code has a very short lifetime and must be used within moments of receiving it.

Exchange Authorization Code for an Access Token

The final step towards obtaining an Access Token is for your application to ask for one using the Authorization Code it just acquired.

Parameters :

curl -X POST \
  'https://api-global.decathlon.net/connect/oauth/token?client_id=fake_client_id&client_secret=djksqljdkjkljkljkqlsjkljdlkqjeidbhebhjbc&grant_type=authorization_code&code=3Qx7Vz&redirect_uri=https://apiproxy-v3.preprod.subsidia.org/connect/oauth/mock_redirect_uri' \
  -H 'Content-Type: application/json' \
  -H 'Postman-Token: f144e6a1-5009-4d19-b85f-057b855d50e7' \
  -H 'cache-control: no-cache'

                                                

Response : Access Token

In response you will get a JSON object containing the following fields:

• access_token: The access token for the user. This value must be secured.
• token_typeThe type of token this is, typically just the string “bearer”.
• expires_inThe number of seconds remaining, from the time it was requested, before the token will expire.
• refresh_token: (optional) can be used to obtain another access token after access_token expiration.
• jti: (optional) The "jti" (JWT ID) claim provides a unique identifier for the JWT.

{
    "access_token": "eyJhbGciOiJSUzI1NEnR5cCI6IkpXVCJ9.eyJzdWIiOiI1YWIxMjY3OC1hYzhmLTRkM2YtOTMzOC02NTJlNzkxZGMyZWEiLCJzY29wZSI6WyJwcm9maWxlIl0sImlzcyI6ImRrY29ubmVjdC5vcmciLCJkYXX2NlbnRlciI6IkVVIiwicGVyc29uaWQiOiI1MDAwMDIzNDcwMSIsImV4cCI6MTU0NTEyNjA2NCwiYXV0aG9yaXRpZXMiOlsiUk9MRV9VU0VSIl0sImp0aSI6IjgxOTgxMTllLWQ4YjktNDc1ZC04MTlmLWExYTQyYWQ5YzNkMCIsImNsaWVudF9pZCI6ImRrY29ubmVjdCJ9.HGNlzYh_mlAmdazSMejNd2totNYChUZ33oZUHo27L_xfWR-C_b8-IUg-MKC0w-Or6zahifqJN5y1NfNlqrsLrAWXFg-ZDAyUYgec3kQmRaFG1AgLFUjwsCvGSYcIGY41PHM0WKRENyU_oDL7bN9AjaOLe3Ob-c2BRWBQu6a5W6fmqugQ28ZFLTGDUTcIcsOdTg0DqBU82B_CjsVrK_x1gLM4y2ozkXJ_OmvCl5CjNsvaYJHKANl8gA5TQgX7IaUAwf7YNcun_rnO1k-FeYoc_OLHWIQG1UDrbDrtUUH-WQo7AE9X5BhgzXjWd1rubv703nbq6RP3BeeoeoJIDQ",
    "token_type": "bearer",
    "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1YWIxMjY3OC1hYzhmLTRkM2YtOTMzOC02NTJlNzkxZGMyZWEiLCJzY29wZSI6WyJwcm9maWxlIl0sImF0aSI6IjgxOTgxMTllLWQ4YjktNDc1ZTlmLWExYTQyYWQ5YzNkMCIsImlzcyI6ImRrY29ubmVjdC5vcmciLCJkYXRhX2NlbnRlciI6IkVVIiwicGVyc29uaWQiOiI1MDAwMDIzNDcwMSIsImV4cCI6MTU0NzcxNzE2NCwiYXV0aG9yaXRpZXMiOlsiUk9MRV9VU0VSIl0sImp0aSI6IjM2NTIyZmZkLWNkZDQtNDE5Ny1iYTVlLWNmNDQ2YzA2OWIzYSIsImNsaWVudF9pZCI6ImRrY29ubmVjdCJ9.5f9tqB1G6qZRpGcVwMQQMtLslNeqX$$$$4Ehi4TFmvVNGofFJpFh-AW5lt-7ye7aKGzYqFdcusDzuuaEDnBnS44qIKUTxomclj1T9BGBYDI5-2PFDFnOaN--ly6dx4vu_TIw9pXJycVCzeq22H5EDrgcF0hbTE4wDQ9lTpV4tDAyYJ3l4QSah9wnWnJQ-Y5rh2v5znQ0Eutu36-tSC_2seII5la_HGrrFuUKNVIu5AJrh_dvs_9Vq-PGu9ODu74bVa8UfMDOEr8sk-ZVvfhiJzzsWBbf7f2wiNneWtA-EhngEA4ZI7RyOeCC_DaGZm6W9N11YyZY-SreFgA",
    "expires_in": 899,
    "scope": "profile",
    "jti": "8198119e-d8b9-475d-819f-a1a42ad9c3d0"
}

                                                

Response : Error

Error responses are returned with an HTTP 400 status code, with error and error_description parameters. The error parameter will always be one of the values listed below.

• invalid_request: Missing parameter or unsupported one
• invalid_client: Invalid client ID or secret
• invalid_grant: The authorization code is invalid or expired, or the redirect URL given in the authorization grant does not match the URL provided in this access token request
• invalid_scope: Invalid scope value in the request
• unauthorized_client: This client is not authorized to use the requested grant type
• unsupported_grant_type: If a grant type is requested that the authorization server doesn’t recognize

{
    "error": "invalid_grant",
    "error_description": "Invalid authorization code: 3Qx7Vz"
}