Good morning, between Yves and Zed … is there some kind of session data that can be used to identify

UPWG9AYH2

Good morning,
between Yves and Zed … is there some kind of session data that can be used to identify the “client” that is performing the gateway call? Or is it a complete new session everytime the client calls the backend?
Background: In our yves frontend on login the app requests a redirect link to an external oauth server login from the zed backend via client layer. There is a state param generated in Zed that have to be represented after the login process again to zed. Usually this param is saved in the session and thrown away when the session is gone. But in spryker when user is redirected to the shop again, it seems, a complete new session is opened on backend calls and therefore no state param can be found in it …
any idea how to “resume” the session for the frontend client again to reach my state param? Ohterwise, I really dont want to implement complete persistence/sanitizing logic just for one string 😕
Any ideas?
Best

Andriy Netseplyayev

Hey Ingo, do you have any sequence diagram for the process? It’s a bit hard to understand who is calling what and the redirects - from where to where..

Andriy Netseplyayev

or maybe step-by-step description of the request sequence..

UPWG9AYH2

Hey Andriy, ill try to explain 🙂
1. User clicks on login in frontend
2. Yves frontend uses a spryker client to get a auth link from the zed backend -> e.g. https://auth.server/auth/realms/test?state=any_random_generated_string&redirect-uri=yves.address
3. Zed persists the state param to compare it later again
4. Yves redirects the user to this link.
5. The user authenticates on the idp server and gets redirected back to the given yves redirect, this looks like https://yves.address/auth-code=auth_code_from_server&state=the_same_random_string_as_given_by_spryker_backend
6. yves uses spryker client to call zed backend with the auth code and state param
7. Zed MUST check if the given state param matches again the stored state param (CSRF attack protection)
8. If not, deny the request for token exchange …
Hope this is now a bit clearer … there is already an implementation for backend login regarding oauth, but here you have no problem storing this param in the session since the session gets resumed for the user using the backend and you will have the state param present

UPWG9AYH2

Problem: On the second call to zed backend the state param generated and stored to the session in the first call is not present since its another session … thats what i observed

UPWG9AYH2

😕

Andriy Netseplyayev

Hey Ingo, I see! But then the questions I would have:

Why involving Zed in the process, in general? Just do the auth on Yves side, and then using Symfony guards let Zed “thrust” that user is authenticated (by token? user_ID? …)

Like this all the redirects and authentication is handled by Yves that has a session

giovanni.piemontese

Why ZED must persist the state param?
If the authentication is for YVES Frontend, why not implement it on Client Level?

Client Layer is not very the best place to put business logic, but in this case i think is the best way..

Naturally in this case the client layer called from YVES use the frontend session..

In the case the auth link can be only generated from ZED, then the return gateway call in client from zed have to save the state param...

Andriy Netseplyayev

@UL65CH0MC 😄 👍 we’ve posted at the same time 🙂

giovanni.piemontese

@UKJSE6T47 just the same reply in the same moment 😄

Andriy Netseplyayev

We have another scenario where Zed is involved - to do Oauth0 authentication with ext. service via Glue API - the idea there is that with the token given by 3rd party system (and passed from Glue to Zed) - Zed would do an external call (machine to machine) to confirm the token, get user ID and generate Spryker’s token and pass it to the frontend for further use. Zed is needed here to load user information into the token such as permissions, company/BU info etc.

Andriy Netseplyayev

But even then, all the redirects and stuff must be handled on the frontend stuff first.

UPWG9AYH2

Hello, thank you guys both for youre involvement 🙂 I struggle from the very first beginning with the question were to put the logic … and to avoid the mentioned problem we decided to go since a while for the client solution … for me it was more or less clear that putting the stuff on the client side was the most logic way … but then i read that on client side its just for yves … but copying the whole logic for zed to business layer of zed is also really not what i wanted to do … so at the moment i also use the client on zed layer with all its logic … but we get now other problems … for example the redirect link differs for zed and yves … since the redirect link is already required when instancing the oauth adapter in the client, we have no chance to “configure” it afterwards when calling the methods on the client … at least not in some intended way^^ … the only thing i could see is to make hybrid client methods like “getFrontendAccesstoken()” and “getBackendAccessToken()” … ugly but i have no better solution at the moment^^

UPWG9AYH2

Hey Ingo, I see! But then the questions I would have:

Why involving Zed in the process, in general? Just do the auth on Yves side, and then using Symfony guards let Zed “thrust” that user is authenticated (by token? user_ID? …)

Like this all the redirects and authentication is handled by Yves that has a session

Thanks Andriy, thats exactly what i do at the moment. The client gets the token, saves it into the customers session and on every request the guard looks if the access token is still valid … if not -> logout and redirect to the login page again …

giovanni.piemontese

I have the same situation as u implemented 1 year ago... i just injected the redirectUri from Yves and Zed, according who start the authentication...

giovanni.piemontese

in Transfer Request Obj if I remember right

giovanni.piemontese

and YvesConfig and ZedConfig have just configured the redirectUri...

UPWG9AYH2

Its a pitty that we cannot play out the strength of the interfaces here … mostly we have an interface like for the Client “XyzClientInterface” with x methods but we can only implement one implementation which MUST be the XyzClient in that case … it would be good if we could have further implementations like “BackendOauthclient” and “FrontendOauthClient” resolvable in the service locator

UPWG9AYH2

Maybe with one param like the redirect uri its not that big thing but think of more changes … injecting all these stuff when calling the client is really ….

Andriy Netseplyayev

my rule of thumb is usually the following: if you don’t need DB for your requests - do it on the Client side. No reason to do round-trip between 2 applications just to generate you a “random token” - something that Client can do perfectly well.

giovanni.piemontese

I think Ingo was a little bit confused after this messages
• https://sprykercommunity.slack.com/archives/CKJRJM5FG/p1629986880012000?thread_ts=1629983959.010700&cid=CKJRJM5FG
• and others messages in thread...

UPWG9AYH2

Exactly @UL65CH0MC … that confuses me because generally i would put the stuff also on the zed side but this time it feels like running from one show-stopper to another. I mean, i invested much time in my current solution which works well except the current config client side stuff which makes me again feels like it will not work because I “violated” the standards and thats now the consequence^^

UPWG9AYH2

Thank you guys in every case. Your insights tell me to have currently something that does not totally miss the target 😉