1 maja 2025 wprowadzimy zmiany w OAuth dla wszystkich aplikacji korzystających z parametru state.

Jak to działa obecnie?

Obecnie serwer Allegro OAuth podczas przekierowania, błędnie obsługuje przekazywanie parametru state, który zawiera znaki zastrzeżone.

Jeśli wysyłasz parametr state:

• zakodowany w adresie URL (UTF-8), zawierający znaki zastrzeżone - Allegro OAuth dekoduje część z nich podczas przekierowania,
• ze znakami zastrzeżonymi - Allegro OAuth przekierowuje z częściowo zakodowanym i częściowo zdekodowanym parametrem state. Odszyfrowane znaki to m.in. / lub +, które nie mają żadnego specjalnego znaczenia w komponencie parametrów zapytania.

Jakie zmiany wprowadzimy?

1 maja 2025 zmienimy sposób zwracania parametru state:

• zakodowanego w adresie URL (UTF-8) - serwer OAuth zwróci wówczas niezmieniony parametr state podczas przekierowania.
• niezakodowanego w adresie URL - przekierujemy użytkownika z zakodowanym parametrem state w adresie URL (UTF-8).

Dzięki temu, pomimo różnych form parametru state przekazanych podczas wstępnego żądania autoryzacji, w przekierowaniu będzie on zawsze zakodowany.

Przykład 1:

Jeśli Twoja aplikacja wysyła żądanie autoryzacji:

https://allegro.pl/auth/oauth/authorize?client_id=<some_client_id>&redirect_uri=http://127.0.0.1:8000/callback&response_type=code&state=%2Fmy%2Fstate%2F%3D 

serwer autoryzacyjny przekieruje użytkownika po pomyślnym uwierzytelnieniu na adres URL zawierający zakodowany parametr state:

http://127.0.0.1:8000/callback&code=<authorization_code>&state=%2Fmy%2Fstate%2F%3D

Przykład 2:

Nie zalecamy przekazywania parametru state innego niż zakodowany w adresie URL, ale jeśli Twoja aplikacja wysyła żądanie autoryzacji za pomocą zwykłych znaków zastrzeżonych:

https://allegro.pl/auth/oauth/authorize?client_id=<some_client_id>&redirect_uri=http://127.0.0.1:8000/callback&response_type=code&state=/my/state/=

Przekażemy parametr state zakodowany w adresie URL, jak w poniższym przykładzie:

http://127.0.0.1:8000/callback&code=<authorization_code>&state=%2Fmy%2Fstate%2F%3D 

O czym musisz pamiętać?

1. Upewnij się, że zawsze wysyłasz parametr state zawierający zastrzeżone znaki jako ciąg znaków zakodowany w adresie URL (UTF-8). Jeśli go nie podasz, dane wyjściowe mogą być mylące, ponieważ będziemy je kodować podczas przekierowania. To samo dotyczy znaków spoza zakresu ASCII: parametr state przekaż jako zakodowany w adresie URL.
2. Upewnij się, że aplikacja kliencka może obsłużyć parametr state zakodowany w adresie URL (w formacie UTF-8) podczas przekierowania. Nie zmienimy Twojego początkowego parametru zakodowanego w adresie URL, pod warunkiem, że przekazujesz go w formie zakodowanej.

Jak możesz to przetestować?

Od 1 maja 2025 przestaniemy udostępniać parametr state w obecnie częściowo zakodowanej formie. Zaczniemy dostarczać niezmieniony parametr state dla zakodowanych ciągów.

Chcemy jednak dać Tobie możliwość płynnego przejścia na nowe rozwiązanie. Dlatego do tego czasu, dla każdego nowo dodanego adresu redirect_uri, udostępnimy niezmieniony parametr state zakodowany w adresie URL. Twoje stare adresy redirect_uri będą zachowywać się tak jak dotychczas (poprzez częściowe dekodowanie parametrów stanu do 01.05.2025). Po tym czasie stare adresy URL przekierowań również będą zawierać w pełni zakodowany parametr state.

W przypadku wysyłania zakodowanego parametru state ze znakami zastrzeżonymi:

1. Dodaj nowy redirect_uri, wskazując punkt końcowy w aplikacji, który może obsłużyć zakodowany parametr state.
2. Przetestuj integrację z OAuth dla nowego redirect_uri.
3. Zaimplementuj nowy redirect_uri na środowisku produkcyjnym. Jeśli stanie się coś złego, możesz to wycofać i nadal używać starego adresu redirect_uri, który zachowuje się tak jak dotychczas.
4. Usuń stary adres redirect_uri, gdy wszystko będzie już działać zgodnie z oczekiwaniami.