Good evening Jimi,
session_uuid, this is used to uniquely identify a specific browser tab. No relation with the authentication process.
same page, the domains of the different services does not matter. You could have shotgun.domainalpha.com, yourapp.domainbeta.com and idp.domaincharlie.com, each defining their own cookies and individual sessions (which makes things confusing sometimes). Once you have authenticated at the IdP, it will generate cookies for itself so that later on when you are back on it, it will be able to tell that are already logged in, and who you are.
Shotgun has its own set of cookies that are set once authenticated. If you are not, or your session has expired, you will be pushed to the IdP and lead back to Shotgun with a payload to identify you. Shotgun then issues you a session. The only information shared between the IdP and Shotgun is the authentication payload (contains you first name, last name, email and shotgun login). Your web application has probably something similar. How your IdP Identity maps the the application identity is, well, application-specific.
I am definitely not an AMI expert (actually, I know very little about those), so please bear with me.
If I understand, in one of your use case, the data flow is like: Shotgun web app -> via an AMI -> your web app -> data back to Shotgun
your web app part, I would assume that if the user is not already logged-in, you would redirect the user to the IdP. Given that this would be a POST call, I believe that you will have to save that to a session before redirecting the user to the IdP as it will not be posted back. In short, if your user is already logged into Shotgun from your IdP, and assuming they are not logged into your app, then going through the IdP will not require the user to type credentials. The IdP cookies will let it know that all is good, and the browser will be redirected back to you application to complete the login and be issued a new session.
For the data back to Shotgun, one solution would be a server-to-server call between your server and Shotgun. You would need to use a Script Name / API Key with admin and sudo privileges, so that your server could connect back Shotgun to do actions on the behalf of the user.
The AMI payload contains the Shotgun user login info, in order to setup the
Doing anything on the frontend side of your app with a REST API calls back to Shotgun will likely not be possible without resorting to exposing sensitive Script Name / API Key information which would be easy to
So I strongly recommend having your server connect to Shotgun directly. Being self-hosted or not should not change things I believe.
Hoping this is semi-clear and helpful.