Sticky cross-action ChatGPT UI sessions

With 30 operations per actions API being the limit right now the only option to have more operations seems to be to break it down into multiple actions (not sure if it’s possible to use oneOf to pack several request types under one operation). The problem I’m facing is that not only Authorization header is per action (which is OK I guess), but both openai-ephemeral-user-id and openai-conversation-id are also unique for different actions within a single ChatGPT UI session.

I need to be able to both identify the user and also confirm they own a remote resource, for which I use OAuth2 (via Custom actions) + a custom MFA (via conversation). But asking the user to do a sign-in and then MFA for each action they want to use looks like an overkill. Is it possible to obtain a unique identifier for a ChatGPT UI session? The only option I see right now is to always ask to sign-in for each API (and obtain Authorization) and hope that the identity provider simplifies subsequent sign-ins. Then I can use the email it returns.

Still I would like to only sign-in once to access 30+ operations across I don’t care how many actions. If I had a unique identifier I can use it as a secret to cache the current session credentials for multiple actions.
Any help is much appreciated, thanks!

1 Like

I saw another authentication method where a user provides an email and it emails a code, etc, and it seemed too cumbersome for me.

I’ve done something interesting recently here as I wanted a user to be able to access the same information on different chats. I implemented continuation tokens.

Basically, when the user interacts with the GPT for the first time they are given a token obtained from the server and sent back to the GPT. On every action the GPT performs on the external server, another token replaces the old one on the same users account and tells it the user when it replies. With this method, the user merely only needs to copy the last ‘token’ from the last message of the last chat to continue in a new chat.

Here is an example chat where I am using this method. The GPT knows to send the newest token to the server on each action, and display the replacement on each reply. On a new chat I just simply give it the last token from the last chat.

Original Chat: ChatGPT
Next Chat: ChatGPT

You can see how the tokens are even share-able as they only last for one action.

1 Like

Thanks for sharing these ideas, @runthis. I agree emailing is a no go as it’s too cumbersome + it adds an area of attack (if someone gets access to email).

The idea about continuation token is interesting, but I have concerns for my use-case.

First, I need any form of “access token” to be short-lived, so that whoever obtains it may not continue to operate on my behalf at a point the future that is too long for me. I guess you can pair this with sign-in and MFA, but then I might as well use Authorization for this purpose and it won’t leak into the conversation (+ it should at least get refreshed by ChatGPT itself). In addition to continuation it will also confirm that “you are who you say you are” because the identity provider verified that (or rather you posses the access to this identity, which even if it’s stolen I cannot do anything about, just hope the real owner addresses/invalidates the breach).

Second, I need to have a form of “physical credentials” to prove that you didn’t simply guess/stole the details about some remote resource that grants custom action the access, it should be something only the user owns that is hard to forge or get access to. E.g. MFA using which I again will generate a temporary access token. All I need is just to map it to some secret on the client side - something short-lived and hard to forge, e.g. Authorization or ephemeral-user-id+conversation-id. Those should not be shared, but even if they get compromised will expire or can be invalidated.

It would have been much easier if I had some control on the client side, e.g. I could have implemented HKDF.

If your GPT has to be that in depth, what about a phone number. While I hate giving out my phone number I always prefer it for verification versus an email. If you have to save it in your database you could easily 1 way encrypt it and let users know you don’t know their number and you only use it to send a 2fa code.

In your case as you described it, a phone number with a 2fa app provides both of those aspects.

I actually had something like Google Authenticator in mind, I don’t need to know (or what) or store the phone number. Ideally I want to store as little as possible, that is the authorized ID (e.g. ephemeral, but sticky user id, or worse case email) and temporary access tokens/credentials (until they expire). I only need a single type of “physical credentials”. E.g. Google Authenticator as MFA, phone can also be used alternatively to click in some app, answer a message or use the token I send - like in the email example you gave).