Edenred Direct Payment Services
FAQ - Authentication flow
What are the different modes used for authentication?
We manage two integration: Redirect_mode and iFrame_mode.
How the authentication pages (sign in and sign out) can be managed?
Authentication pages (sign-in & consent) are displayed in a web browser, they can be integrated as full page, iframe or WebView. We recommend full pages or WebView integration to limit the number of display errors that may be encountered via an iFrame implementation (browser security can block such implementation).
Can I manage authentication flow via API?
No, for security reasons, Edenred must expose the screens (and APIs exposed behind each screen). The only adaptation allowed is the display of your logo (only if the authentication flow is in Redirect_mode)
Is it possible to manage different language?
Yes, with the localizations, variable called "ui_locales". Please refer to the Use case description per country to list the supported language in the country.
Can I add my logo on the authentication page?
Yes, in redirect mode only. It will be displayed on the authentication pages. Please provide the URL of your logo so that we can integrate it in your dedicated configuration.
What format is supported for my logo on the authentication page?
The logo must be in SVG and will be displayed with a maximum width of 134 px.
To what extend "login" and "logout" URLs refer to?
Both are callback URL, the first one allows the user to be redirected when he authenticated in success while the second one redirects the user after the logout.
Can we whitelist a domain?
• For the management of the redirect URL: No, we can only manage the exact URL. You can manage as many URL as needed on each environment.
• For the management of the frame ancestor: Yes, a domain can be added (simply include the star wherever needed in the URL).
What are the different scopes referring to?
We manage 3 scopes:
• openID: it allows the partner application to verify the user's identity
• edg-xp-mealdelivery-api: it allows the partner to access to the various APIs of the payment scope
• offline_access: it allows the partner to generate & manage refresh_token"
How is the merchant identified? When?
The merchant is identified in the payment request via the MID (Merchant Identifier) as defined in the Edenred payment loop. This information is provided by Edenred on the merchant onboarding.
How to secure communication in the authentication flow?
Use the “nonce” exposed in the authentication URL. This attribute secures the communication. The “nonce” you have generated and provided in the authentication request will be sent back in the "token_id" generated at each token request. Via an introspection of this token, you can check its validity.
How to manage dynamic information in the authentication flow?
We define "Dynamic" information: user, context on your platform... So, use the "state" exposed in the authentication URL to manage the dynamic information.
What state stands for?
Authorization protocols provide a "state" parameter that allows a partner to restore the previous state of your application. The state parameter preserves some state object set by the client in the Authorization request and makes it available to the client in the response.
What nonce stands for?
The nonce is a string value (case sensitive string in a cryptographic hash) used to associate a Client session with an ID Token, and to mitigate replay attacks. The value - unmodified - is passed through from the Authentication Request via the "ID Token".
Provided by Edenred in the "ID Token", the partner MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request.
What is the token_ID and what information are provided in it?
The Identity token (token ID) is a JWT (standalone) token containing information about the user, the nonce and other authentication process (https://jwt.io)
It has a very short lifetime (see OpenID Connect specs for more information about token ID structure). Decoding it locally (via an introspection) gives this information directly without calling identitytokenvalidation endpoint.
Example:
{
""iss"": ""https://sso.sbx.edenred.io"",
""aud"": ""bf79413250f449948ce12b98b08e3fc0"",
""exp"": 1577716759,
""nbf"": 1577714959,
""nonce"": ""9b30a072-fb8a-4d1b-bf80-157b1842ecfd"",
""iat"": 1577714959,
""sid"": ""c8db0d3d0f26b42347452ec19ed59da8a7d219a136825c15e9cc267866cb2795"",
""sub"": ""fr-ctrtku\charette@yopmail.com"",
""auth_time"": 1577713782,
""idp"": ""idsrv"",
""username"": ""charette@yopmail.com"",
""tenant"": ""fr-ctrtku"",
""amr"": [
""password""
]
}"
Can you provide an example of the use of nonce and state in the authorization flow?
Request:
Authorization request generation on partner side contains the "state" and "nonce" generated by the partner.
https://sso.sbx.edenred.io/connect/authorize?response_type=code&client_id=bf79413250f449948ce12b98b08e3fc0&scope=openid%20edg-xp-mealdelivery-api%20offline_access&redirect_uri=http://nowhere.edenred.net/oauth/callback&state=abc123&nonce=456azerty&acr_values=tenant%3Afr-ctrtku&ui_locales=fr-FR
Response:
The "state" is provided in the authorization response. When the user is logged in, the redirect_response contains the authorization code generated:
http://nowhere.edenred.net/oauth/callback?code=085216205f936af8dde987e0fc3413b780efd24184801af2bc5a59636ecf81d3&state=498a3409-6716-4527-927e-bd19f9066c03&session_state=iV1EHS79LPfvWFDPZjEshrUeKJ2uoJECfV1j4lIdP9Q.c7ca35e35d7c6345fd6f5ba3b9f4cbc8bbc0e04447c3dd60e30d1f185c393320
The "nonce" is provided in the token generation process
• Generate tokens by providing the valid authorization code
• Retrieve the 3 tokens provided by Edenred: Refresh_token, access_token and ID_token
• Decode the ID_tokens and check the ""nonce"" via an introspection"
What is the tokens lifetime?
We set a default configuration for the token management by integration mode.
API mode
• Refresh token: 30 days
• Access token: 60 minutes
P&P mode
• Refresh token: No refresh
• Access token: 10 minutes
How to retrieve the refresh token in the authentication call?
The scope "offline access" must be added in the authorization request URL.
When refreshing a token, is there a difference with the previous response format?
Response format is the same in each request type (request a token from an authorization code and request a token from a refresh token). The 3 tokens are refreshed on each request.
Where the tokens should be stored?
Tokens must be stored securely on the server-side.
How to manage a user with a refresh token expired?
This is not possible. A new set of tokens must be generated via the re-onboarding of the user. An invalid refresh token should trigger the onboarding of the user.
How to manage integration without a backend? Direct from mobile?
The integration must be managed in a PKCE mode (as for security reason, the secret can't be stored in the front-end device).
How to handle display issues in iFrame mode?
Our authentication layer uses some React JS component.
• The user must accept the cookies on the browser to enable the display.
• If this is still not working, please report the issue to the support team with the maximum information so that we can replicate and investigate (browser, browser version...).
Can I get test data in production?
Yes, to get one user and one merchant to perform a test, please contact your local project/business manager.