Uploading without an API key in sight

The first time a creator connects a channel, they sign in to Google. They see a consent screen. That screen lists exactly what Autoretto can do: upload videos to the connected channel. The creator picks the account, accepts, and Google sends a one-time code to our server. That code only lives for a few minutes. It cannot upload anything on its own. This is the last moment the creator has to think about credentials.

The code marks the end of the creator's involvement. The server swaps it for two tokens. An access token is short-lived. A refresh token is long-lived. Google designed this couple so apps do not need to hold a password. The access token opens the channel door. The refresh token exists to issue new access tokens later. Neither token is shown to the creator. Neither one appears in a browser after the handshake.

The access token is what actually uploads a video. It expires after about an hour. The refresh token can keep minting fresh access tokens for months. That makes the refresh token far more valuable. So Autoretto protects it like a key to a safe. We encrypt the refresh token before it touches our database. The encryption key lives in a different place on the server. If one part is compromised, the other part is not automatically exposed.

Each connected channel has its own row in the system. That row holds the encrypted refresh token, the YouTube channel ID, and the basic profile details we need for scheduling. One channel's refresh token cannot unlock another channel. Even if the same Google account controls two channels, each channel gets its own encrypted token. The scope of the OAuth grant is limited to the one channel the creator selected during consent.

At upload time, no developer or creator is in the loop. The scheduler decides a video is ready. The publisher pulls that channel's encrypted refresh token from the database. It decrypts it in memory. Then it calls Google's token endpoint to request a fresh access token. This new access token is valid for one hour, which is more than enough to upload a single video. The access token never touches a disk. It lives in the process only until the HTTP request completes.

That short lifetime is a deliberate safety measure. If an access token gets intercepted while the video is being sent, an attacker can only use it for a short window. The refresh token, on the other hand, is transferred less often. It only travels from the database decryption step to the token endpoint in memory. Most of the time it sits still in encrypted form. An attacker who steals the database cannot reuse the tokens because they are unreadable without the separate key.

This layout means the creator never handles an API key. They never copy a client secret into a file. They never rotate OAuth credentials on a calendar. The one-time Google grant is all it takes. If they ever want to disconnect, they can revoke access from Google's security page. The stored refresh token stops working. The next scheduled upload fails cleanly, and the dashboard asks the creator to reconnect. Reconnecting runs the same OAuth flow and updates the stored token.

We have run this system for many releases. It is the reason a completely hands-off channel can keep publishing without a single key sitting on someone's laptop. The burden is on our server to handle secrets correctly, not on the creator to babysit them. Each upload uses a token that was minted seconds earlier, used once, and thrown away. That keeps the channel connected, and it keeps the channel safe.