Most people never think about authentication until it fails, and when it fails it fails in one of three ways: you cannot get in, you keep getting thrown out, or you are in but on the wrong screen. This guide covers all three, plus the one confusion that generates more support messages than the rest combined — the difference between signing in with Google and connecting YouTube as a platform.

Four ways to sign in

Email and password. The default. You enter an address and a password and you are in. This is the path most teams standardise on because access can be handed over and revoked without touching a third party.

Google. A redirect to Google's own consent screen, then back to PostHub. Uses the Google OAuth client configured for sign-in on the server.

GitHub. The same redirect pattern, for the developers who would rather not type another password.

A one-time email code. Signup always works through a code rather than an immediate login, because verifying that you own the address is the whole point of the first step.

There is no shared demo login. Each workspace starts empty and fills up as you connect accounts, which is also the only way to see it holding your own platforms.

Signing up, step by step

The signup form asks for a name, an email address and a password. Submitting it creates the account in an unverified state and sends a six-digit verification code to the address you gave.

Open the email, copy the code, enter it on the verification screen, and you are signed in. The welcome email arrives at roughly the same time as the code; if you do not see either, check the spam folder before anything else, because automated mail from a new domain lands there more often than anybody would like.

If the code does not arrive, the verification screen has a resend action. Wait for the first one to have a realistic chance of arriving — email is not instant — then resend. Requesting five codes in thirty seconds does not produce five working codes; it usually produces a rate limit and a longer wait.

Three things go wrong most often at this stage. The address has a typo and the code is sitting in someone else's inbox. The code from an earlier attempt is being used after a newer one was requested, which invalidates the old one. And the password is entered twice with a difference so small it is invisible — the confirm field is unforgiving, and retype rather than assume.

Once verified, you are signed in and your session begins.

What keeps you signed in, and what does not

Two cookies do the work, and they have different lifetimes on purpose.

The access cookie lasts thirty minutes. It is what your browser sends with every request, and it is httpOnly — meaning JavaScript running on the page cannot read it, which is the property that stops a script injection from quietly stealing your session.

The refresh cookie lasts seven days. It is not sent on every request; it is used only when the access cookie has expired, to mint a new one.

That split is why the app behaves the way it does. Half an hour after you stop interacting with it, the first request you make will come back as an unauthorised response, the front end will use the refresh cookie to obtain a new access cookie once, and then replay the request you actually asked for. From your side, nothing happens — you do not see a spinner, a message or a flash of the login page.

If the refresh cookie has also expired — seven days of not using the app — then there is nothing to refresh from, and you are redirected to the login page with a next parameter carrying the page you were trying to reach. Sign in and you land exactly where you were going.

The practical consequences: leaving a tab open overnight is fine, because the refresh happens silently. Coming back after a week is not, because the refresh window has closed. And signing out deliberately clears both, which is why logout works even if you were in the middle of something.

Both cookies are set with SameSite=Lax, so they are sent on normal navigation from the same site but not attached to cross-site POSTs — that is what stops a form on an unrelated domain from acting as you. On a production deployment served over HTTPS they are also marked Secure, so they travel only over encrypted connections.

The next parameter: why you land back where you were

Every protected screen in the app, when it finds you signed out, redirects to the login page with the destination encoded in the URL as next. After you authenticate, the app reads that value and sends you back.

It works for the whole path, not just the route — if you were deep in a post's detail page with a filter applied, you return to that exact place rather than to a generic dashboard.

Two details worth knowing. If you open a login link that already carries a next value and you are already signed in, the app skips the form and takes you straight to the destination — which is why clicking a bookmarked protected page can appear to "do nothing" for a second before the dashboard appears. And the value is validated before it is used, so a next pointing at a different domain is ignored rather than followed; you land on the dashboard instead of being sent somewhere else.

If you ever arrive at the login page unexpectedly and the address bar shows a next you did not expect, that is this mechanism working — something tried to take you to a page you could not reach. Sign in and you will get there.

Forgot your password

The forgot-password page takes your address and sends a reset mail. The reset page it links to asks for a new password twice and commits it.

The rules that apply here are the ones that apply to every reset system. The link is single-use and time-limited, so asking for a new one invalidates the previous. The address has to be the one on the account — requesting a reset for a slightly different address produces a successful-looking flow that changes nothing. And the mail comes from the application's sending domain, so if the first reset never arrives, the spam folder and the spelling of the address are the first two things to check.

If the reset mail genuinely will not arrive, the usual cause on a new deployment is that the sending key has not been configured on the server, which is an infrastructure fix rather than something you can work around from the login screen. The error from the forgot-password request will name what failed.

Once the password changes, any other browser signed in with the old one keeps its existing session until that session expires or is cleared. If you are resetting a password because you think someone else has access, change the password and sign out everywhere you can see, then check the connected-apps list on any Google or GitHub account you have linked.

Signing in with Google or GitHub

Both work by redirecting you to the provider, letting you approve there, and bringing you back. There is no local password to remember for those accounts, and the provider's own session determines whether you have to type anything.

The redirect goes back to the same application origin, and the session cookies are set on arrival exactly as they are for a password login — the thirty-minute and seven-day rules are identical. Switching between Google sign-in and password sign-in does not create two accounts, provided both are attached to the same email address; the account is keyed by the address, not by the method.

If you sign up with Google first and later try to log in with a password, you are creating a different path to the same address and the password you choose has to be set through the normal reset flow, because a Google-created account may not have a password of its own yet.

The confusion: Google sign-in is not YouTube

This is the single most common misunderstanding in the product, so it gets its own section.

Signing in with Google is how you prove who you are to PostHub. It uses one OAuth client configured on the server, it produces a session cookie, and it has nothing to do with publishing.

Connecting YouTube as a platform is how PostHub proves who you are to Google when it uploads a video on your behalf. It uses a different OAuth client, it is configured with the YouTube Data API enabled, it requests upload and readonly scopes, and the result is a stored token against a connected account rather than a session.

They use different credentials, different scopes and different redirect paths. Configuring one does not configure the other, which is why it is entirely possible to sign in with Google every day while YouTube still shows as Keys missing on the Connected Accounts page.

The same split applies to GitHub: signing in with GitHub is authentication, and no platform in the product publishes to GitHub.

If you remember one sentence from this guide, make it that one.

Changing your details after you are in

The settings screen has four tabs.

Profile saves your display name, email and avatar preferences through the same endpoint that serves the rest of your account record. Changing your email changes the address that password resets and receipts go to, so it is the one field worth being careful with.

Notifications controls which in-app alerts you get. These are preferences rather than outbound mail — they change what the bell in the top bar shows you rather than what lands in your inbox.

Team in this build is a static view rather than an invitation system. There is no pending-invite flow, no role assignment and no email that goes out when you press the button, so treat anything you see there as a preview of the workflow rather than the workflow itself.

Signing out, and shared computers

The logout action clears both cookies and returns you to the login page. It is the correct thing to do on any machine you do not control, and on a machine you do control it is still worth doing before you hand the laptop to someone else.

Because the access cookie is httpOnly, there is nothing you can do from the browser console to copy a session to another tab or another person. That is the property that makes a shared or public computer survivable: as long as you sign out, there is no token sitting in page memory for the next person to find.

On a public computer, sign out, and then close the tab. If the browser offers to remember the password, decline — that is stored by the browser rather than by PostHub and it survives your logout.

Troubleshooting

You are bounced to login while typing. The access cookie expired mid-session and the refresh also failed — usually because the session is older than seven days. Sign in once and the next parameter returns you to the page you were on.

You are bounced repeatedly, immediately after signing in. Something is clearing or refusing the cookies. The two usual causes are accessing the site over a different host than the one that set them (a www and non-www mix, or an IP address instead of the domain), and a browser blocking third-party or site cookies entirely. Try the canonical domain in a normal window first; if that works, the problem is the browser's cookie policy rather than your account.

The login page keeps reappearing after a successful login. Same cause as above, seen from the other side: the cookie is set and then not sent back. Check that you are on https, that the address matches the canonical domain exactly, and that your browser is not in a mode that discards cookies on navigation.

The verification code is rejected. A newer code was requested after the one you are using, or the digits were transcribed with a smart-quote character from a rich-text mail client. Use the resend action and type the digits rather than pasting them.

You can sign in but land on the dashboard instead of the page you wanted. The next value was missing, expired or pointed outside the site, so it was deliberately ignored. Navigate to the page directly; the session itself is fine.

Google sign-in says the app is in testing mode. That is the sign-in OAuth client on the server being restricted, not your account. Either the deployment's client needs you added as a test user, or the password path is the one to use in the meantime.

Password reset mail never arrives. Check spam, confirm the address, then confirm with whoever maintains the deployment that the mail sending key is configured and that the sending domain has the DNS records a new domain needs to get past spam filters.

The demo button works but your own account does not. The demo account is pre-verified and pre-populated. A newly signed-up address has to complete the email code step first, which the demo button skips by design.

What to check before you ask for help

Four facts resolve almost every access question without a back-and-forth:

Which method you are signing in with — password, Google, GitHub or the demo.

Whether the failure is at signup, at login, or after login when a page redirects you back.

The exact address in the bar when it goes wrong, including any next parameter.

Whether the site is being opened over the canonical domain and https.

A screenshot of the address bar with the next value visible tells you more than a description of "it keeps logging me out", because the parameter names the page that triggered the redirect and therefore the permission or session state involved.

Multi-device sessions: what is running where

There is no active-sessions list in this build, no device names, and no sign-out-everywhere button. That is a gap rather than a design, and it shapes what you can and cannot verify.

What actually exists: one pair of cookies per browser. Signing in on your laptop does not sign you out of your phone, and signing out of one does not touch the other. Each browser holds its own access cookie with its own thirty-minute life and its own seven-day refresh window, and they are entirely independent of each other.

The consequence is that "is anyone else signed in?" cannot be answered from inside the product today. What you can do instead is work from the outside in. If you suspect unauthorised access: change the password, which stops new logins; sign out of the browsers you can see; then check the connected-apps lists on your Google and GitHub accounts for grants you do not recognise. That combination covers the realistic exposure, because the only ways into the account are the login paths and the provider accounts attached to them.

A useful habit for teams: keep one account per person rather than sharing one, even though sharing works. The day somebody leaves, the shared account has to be reset by everyone, whereas a personal account simply stops being used. The Team tab's limitation — no seats, no roles — makes this the only offboarding mechanism available today, and it is worth adopting deliberately rather than by accident.

Access problems that are not your password

Nine times out of ten a login problem is a password problem. The tenth is one of these, and they all look identical to a wrong password until you check.

The canonical host. Cookies set on one host are not sent to another. Opening the site at both the bare domain and a www variant, or arriving through an IP address instead of the domain, produces a cookie that is set and then never returned — which looks exactly like a login that will not stick. Pick the canonical address, use it everywhere, and close any earlier tab on the wrong one.

Cookie policies. Strict tracking protection, some enterprise browser profiles, and privacy extensions that block site data will discard the session. Incognito usually works as a diagnostic: if a clean window signs in successfully and your normal window does not, the account is fine and the browser configuration is not.

Extensions. Password managers and privacy extensions are the two that interfere most, either by auto-filling the wrong credentials or by stripping cookies after they are set. Testing with extensions disabled separates the two cases in a single attempt.

Clock skew. Verification codes are validated against the server's clock, not yours. A device with a badly wrong clock can request a code, receive it, and still have it rejected because the time it recorded does not match the server's window. Fixing the device's time sync fixes the code.

Proxies and filtering. Corporate networks, VPNs and DNS-level blockers can alter or drop the redirect leg of Google or GitHub sign-in. The failure usually happens on the way back from the provider, and switching the VPN off for thirty seconds is the fastest test.

Wrong identity entirely. Signing in with a work address when the account was created with a personal one — or vice versa — does not produce an error. It produces a brand new empty account, which reads as "my dashboard is missing". Check the address in the top bar before assuming content was lost.

Each of these has a one-line test, and running them in order takes less time than describing the problem to anyone else would.

Offboarding: when somebody leaves

Because there are no roles, the procedure is manual, short, and worth doing in this order.

Change the password first. That stops the door for anyone using the login path. Use forgot-password if the person who left was the one who knew it.

Disconnect every platform inside the product. Each disconnect deletes the stored token for that connection, so publishing immediately stops working for anyone who gets back in.

Revoke PostHub from each platform's connected-apps list. This is the step people skip and it is the important one — it invalidates the grant at the source, which covers the case where a token copy survived somewhere unexpected.

Review what they created. Posts, drafts and media belong to the account rather than to the person, so anything scheduled by a departing colleague is still scheduled. Read the queue and decide, deliberately, what should go out in their absence.

Remove their way back in. If they signed in with Google, their ability to return is governed by that Google account, which you do not control — the password change and the platform revocations are what matter on your side.

An hour of this, once, is cheaper than an incident report later. The security guide covers the same ground from the threat-model side if you want the reasoning rather than the checklist.

The demo account, and how to evaluate safely

The demo credentials on the login page exist to remove the twenty minutes between arriving and seeing a working product. They are worth using correctly, though.

What it is good for: seeing the dashboard populated, walking the calendar, the queue and the composer, checking how posts look once they exist, and deciding whether the workflow suits you before you have connected anything real.

What it is not for: real content. Anything you type into the demo account belongs to the demo account, and other people evaluating the product may be looking at the same one. Draft your actual posts in your own account.

Whether it can publish depends on the deployment: if the demo user has no connected platforms, a publish attempt fails with a not-connected message, which is correct behaviour rather than a broken feature. Connecting a platform to the demo account would also mean connecting your platform to a shared login, so don't — create your own account instead, which takes about two minutes: name, address, password, six-digit code from the email, and you are in with a session nobody else shares.

Why emails go missing

Codes, verification mail, welcome mail and password resets all travel the same path, and they all fail for the same four reasons.

Spam. Automated mail from a domain that has not built a reputation yet lands there. This is the first check, always, before any technical investigation.

A mistyped address. The signup field accepts anything shaped like an email. An address with a transposed pair of letters sends real codes to a real stranger, and the flow looks entirely successful from your side.

A newer code invalidating the older one. Requesting a resend after a slow first attempt means only the newest code is valid. Using the first one produces a rejection that looks like a bug.

Sending not configured. On a deployment where the mail key is missing or the sending domain lacks the DNS records a new domain needs, nothing leaves the machine. The forgot-password request reports what failed, and the fix belongs with whoever maintains the server.

Rate limits round it off: a handful of rapid requests produces a pause rather than five codes, and waiting is the correct response. If one email arrives and the next does not, deliverability is working and the problem is the request rather than the infrastructure.

The password part nobody enjoys

Password advice has a reputation for being both obvious and ignored, so here is the short version with the reasoning attached to each piece.

One password per site, without exception. Not because reuse is impolite, but because a breach anywhere else arrives at your login as a ready-made key. Password managers exist precisely so that this costs nothing in effort — the marginal cost of a unique password is zero once the manager is installed.

Length over complexity theatre. A long passphrase of four unrelated words beats a short string of symbols that you will recognise by pattern and therefore reuse. The goal is a password you cannot remember, held somewhere that can.

Treat the email address as the identity. Your PostHub login is keyed to the address, not to the method. That has two consequences worth internalising: losing access to the address means losing the ability to reset, and signing in with a different address creates an entirely separate account rather than a second door to the same one.

Reset when the password is exposed, reconnect when a platform grant is exposed. These are different events with different fixes, and mixing them up wastes time. A password problem is solved on the PostHub side with forgot-password. A suspected token problem is solved on the platform side by revoking the application from its connected-apps list. If you cannot tell which you have, do both — they are each a minute.

Be careful with the demo credentials. They are printed on the login page for evaluation, which means they are public and shared by design. Never connect a real platform to the demo account, never store real content in it, and never use a password of yours anywhere it appears.

After any suspected exposure, change the password before investigating. The order matters: closing the door first means that whatever you learn during the investigation cannot be acted upon while you learn it. Then revoke the platform grants, then look at how it happened.

The whole of it fits in one sentence: a unique password in a manager, an address you control, and a reset the moment either is in doubt.

Signing in from a phone, a tablet or another browser

Every device gets its own independent session, which is simple in principle and worth a few sentences in practice.

On a phone, the same login applies and the same cookies are set, with one difference that catches people out: mobile browsers are more aggressive about discarding site data under storage pressure, and a phone browser in a low-power or private mode may end the session far sooner than seven days. If your phone keeps signing you out while your laptop stays in, that is the browser's storage policy rather than a problem with the account.

Signing in on a second device does not affect the first — there is no single-session policy — so you can have a laptop, a phone and a tablet all active at once, each with its own thirty-minute access window and its own seven-day refresh window. They expire independently, which is why one device can bounce you to the login screen while another is still happily signed in.

Private or incognito windows are worth understanding as well: their cookies disappear when the window closes, so a session established there ends with it by design. That makes them the right place to test whether a login problem is caused by your normal browser's extensions or cookie policy, and the wrong place to leave a session you intend to come back to tomorrow.

The rule that covers all of these: the session belongs to the browser and the device, never to the account alone. Sign out on anything you do not control, and expect to sign in again on anything that throws data away.

Questions worth answering before opening a ticket

Can I change my email address? Yes, through Profile. It changes where resets and receipts go, so confirm the new address is one you can receive mail at.

Can two accounts share an address? No. The address is the identity, so a second account with the same address is not something you can create — which is also why signing in with Google and with a password can land on the same account.

Does Google sign-in ever see my PostHub password? There is no PostHub password in that flow at all. The provider authenticates you and PostHub receives a confirmation.

Will I be signed out mid-work? Not while you are using it. The refresh happens silently thirty minutes after the access cookie expires; you are only bounced if the seven-day refresh window has also closed.

Is there two-factor authentication? Not in this build. The compensating controls are short sessions, httpOnly cookies and revocable platform grants, and the honest advice remains: use a password you use nowhere else.

Do scheduled posts keep publishing if I stop logging in? Yes, as long as the account exists and its platform connections remain valid — the scheduler runs on the server, not in your browser. Nothing depends on you being signed in, which is the point of a scheduling tool and also the reason platform connections are worth checking once a month.

What happens if I clear my browser data? Your session ends and you sign in again. Nothing about the account, the scheduled posts or the connections is affected, because none of them live in the browser.

The short version

Sign up with an email code, sign in with a password or a provider, and let the thirty-minute access cookie and seven-day refresh cookie handle the rest silently. Use next to get back to where you were going, use forgot-password when the password is gone, and remember that signing in with Google has nothing to do with connecting YouTube as a platform.