Updated at 02/25.
The app uses different methods of authentication for different endpoints. This document aims to document what I have learned.
Using most functions of the Edeka app (unsurprisingly) requires an edeka account.
Somewhat recently, a modern passwordless authentication flow using OAuth 2.0 with OpenID Connect (OIDC) and PKCE (Proof Key for Code Exchange) has been introduced.
On login, the email address is collected from the user, to which an email is sent, containing a magic link to https://newsletter.edeka/go/ (?) that redirects to https://login.edeka/auth.
The flow then uses a custom mobile scheme (edeka://) when the link is clicked from a mobile device, which is used to try to open the edeka app, where the authentication is completed and stored.
If the link is clicked from a desktop machine, a one-time code generates in the browser on the desktop, which can then be entered in the app to complete the authentication.
In addition, AWS WAF is used to protect some endpoints critical for the authentication flow.
I have only noticed to small problems with the implementation:
- Repeated logins using a desktop and phone will only work up until the one-time code has to be entered in the app. The code generated by clicking the valid link will not be accepted. This may be a bug or rate-limiting. Thus, login → logout → login may not work.
- If the login happens on one phone, but the link is clicked on a different phone, the phone to be logged in recognized that the link was clicked from a different device and now expects a one-time code, but the other device just opens the edeka app and does not show the code.
Edeka uses a retail software stack offered by GK Software SE, which can be verified by visiting GKs website under customers and on the german version of the page in the footer under "Was unsere Kunden sagen".
This system handles the underlying processes used by most of the apps features, including receipt generation, coupons, offers and the loyalty program. The software was initially developed by valuephone GmbH, which GK Software aquired in 2018. After initial authentication using the bearer generated by a successful login with an Edeka account, the app communicates directly with this backend currently hosted under https://myvaluephone.de using SOAP requests.
This package aims to implement the authentication flow used by the Edeka app as closely as possible, in doing so preventing spam and misuse where possible.
The first step is always an anonymous registration. This is where information about the app, device and user language is exchanged for what the app calls user:password credentials. Because both of these values are generated mostly randomly, I am calling them ID and Secret instead. These credentials can then be used to either try out the app without an account or to log in with an existing account. If the user chooses to log in, the described Edeka OAuth flow is executed. Afterwards, the anonymous credentials as well as the bearer are exchanged for a new set of credentials that can be used to authenticate with the GK Retail backend. These credentials are then verified, before a checkin happens with the api that tracks platform, app version and country.
The credentials generated by me initially are still valid. It is unknown if and when they expire, but the validity seems to be at least a year (!). They are seemingly not invalidated by a logout from the app, or at least not immediately. The only way I've found to invalidate credentials is by generating new credentials using the same device configuration (probably bound to imei+email). For one account, there can be multiple active devices.
As such, to prevent spamming registrations for devices when using the api, we not only need the credentials, but also the device information used to generate them. This is implemented using a plaintext json file that is saved to disk and can then be loaded. These contain plaintext credentials and should obviously be treated carefully.
All of this is implemented in authentication.go.