Décoder le State renvoyé par OKTA

Support
1

Request description

Bonjour,

Notre Use case est le suivant :

  • un utilisateur accède à un formulaire via une URL deeplink qui lui est transmise par mail
  • il se connecte dans un premier temps avec OpenIdConnect
  • si la connexion est OK, il accède à son formulaire → cela fonctionne
  • si la connexion est KO, il est connecté avec un user générique lui donnant accès à ce formulaire uniquement, + un popup de demande de compte qui crée chez nous un JIRA → cela ne fonctionne pas car au retour KO d’OKTA, nous avons perdu le deeplink

Il me semble que nous pouvons retrouver ces informations dans le paramètre State de la réponse OKTA, mais je ne sais pas comment le décoder. Auriez vous des pistes pour moi ?

Merci d’avance !

Emmanuelle

[Platform]
Status=OK
Version=6.2.15
BuiltOn=2025-08-15 11:39
2

Qu’est ce qu’est “OKTA” ?

Si on parle d’un IdP genre SAML ou OpenIDConnect il faudra regarder les flux HTTP de près pour voir la séquence précise et ce qui est passé sur chacun des échanges, et en particulier l’appel final qui revient sur Simplicité (ex: sur Chrome: F12 + onglet “network”)

1 Like
3

Oui c’est un Idp OpenIdConnect.

Dans Network je vois passer 3 GET

  • vers BASE URL + deeplink + provider=oauth2Okta
  • vers le authorize du SSO avec le State dans l’URL
  • vers le oauth2callback avec l’erreur User not assigned et le même State

Mais mon idée est surtout que si le deeplink est bien retrouvé après une connexion OK, on a peut-être un moyen de le récupérer aussi si KO ?

4

Je lis entre les lignes qu’on parle d’un “SSO” OpenIDConnect.

Le state que nous générons et qui est visiblement bien fourni en retour par l’IdP, y compris en cas d’erreur, ne contient pas de données significatives.

Un éventuel deeplink dans l’appel d’origine est bien géré en cas de retour OK mais pas en cas de retour en erreur, ce qui est logique car on est pas sensé arriver alors ailleurs que sur une page d’erreur.

Dans votre cas il faudrait donc que vous surchargiez la gestion d’erreur via le platform hook customErrorResponse en y récupérant le deeplink dans la session Tomcat si celle ci est bien toujours accessible (à tester mais je pense que c’est le cas) via request.getSession().getAttribute(Globals.SESSION_DEEPLINK)

1 Like
5

Merci c’est parfait !

6

Tant mieux mais attention cette “solution” n’est pas garantie dans le temps car on envisage de ne plus avoir recours à la session Tomcat pour ce genre de choses à l’avenir (i.e. en v7+)

7

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.