Why a website login may fail inside a web-app wrapper

Most websites sign in normally behind PWA Lock. The ones that fail almost always do one of two things during login: they send your browser to another address partway through, such as a sign-in provider or a different subdomain of the same site, or they check which address they are being served from and stop when it is not their own. Neither is a bug in the site or in the lock; it is how the site was built, which decides whether there is a workaround. We make PWA Lock, so it is the example here, but the same mechanics apply to any wrapper that fetches pages through its own servers.

What does a wrapper change about a website?

When you open a locked app, your browser talks only to the locked address, such as my-notes.pwalock.com. PWA Lock's servers fetch each page from the original site and return it under that address, doing a few specific things on the way:

• Links and requests that spell out the original address are rewritten to relative ones, so following them keeps you inside the lock. Only the domain you entered when creating the app is rewritten; any other subdomain or domain is left alone.
• Redirects back to the original site are made relative too. A redirect anywhere else is handed to your browser unchanged, and the browser follows it out of the lock.
• The site's own cookies pass through in both directions. A cookie the site sets is stored for the locked address (PWA Lock removes the Domain attribute, which would name the original site and make the browser refuse it) and is sent back on later requests. PWA Lock's own cookies, such as your account login and the unlock, are never forwarded to the site.
• A small block is added to the top of each page: the icon and manifest that make the locked address installable, and a script that relocks the app when you switch away. Otherwise the page passes through as the site sent it.

Three things look different to the site. The Origin and Referer headers your browser sends name the locked address, and PWA Lock forwards them as they arrive. The site's own scripts see the locked address when they look at the current hostname. And requests arrive from PWA Lock's servers, not your phone. Everything else is as usual: its own hostname in the Host header, the path, your form entries, and every cookie it set through the lock. All of it passes through PWA Lock's servers in memory and is not intentionally stored; What PWA Lock protects, and what it does not spells out that boundary.

Which login designs fail, and why?

Why does a sign-in provider take you out of the lock?

Sign in with Google, Apple and most other log in with buttons use OAuth 2.0 or a protocol built on it. RFC 6749 gives the flow a fixed shape: the site sends your browser to the provider, you approve there, and the provider sends your browser back to a return address the site registered in advance, refusing any other. That refusal protects your account with the site; it is a feature, not a quirk.

Through the lock, the very first step leaves. The redirect to the provider is not a redirect to the site, so PWA Lock hands it to your browser untouched, and the return trip goes to the registered address, the original site, where you arrive signed in while the locked address knows nothing about it. PWA Lock cannot add itself to the site's registration.

What can you try?

1. Use the site's email and password login. Most sites with social sign-in also offer one. That form posts to the site itself, the cookie it sets in reply is stored for the locked address, and every later page carries it. If social sign-in is the only option, the site will not work behind the lock.
2. Check the address you gave PWA Lock. Sign in to the site in Safari and look at the address you end up on. If it is not exactly the one you entered when creating the app, the lock guards the wrong door. Apps cannot be edited yet, so create a new app with that address, following the setup guide, and ask contact@pwalock.com to remove the old one, which counts toward your plan's app limit until then. That Safari login stays in Safari: cookies are kept per address, and PWA Lock forwards only what your browser sends to the locked one.
3. Point an email sign-in link at the lock by hand. Such a link names the original site, so tapping it opens the site in Safari, outside the lock. Instead, copy it, replace the site's domain with your locked address, keep the rest, and open it while the app is unlocked. PWA Lock fetches the same path from the site, and the cookie set in reply is stored for the locked address. This works only when the link names the domain you entered when creating the app.
4. Try Safari and the installed app separately. iOS gives an installed web app its own cookies and storage, separate from Safari, so a login in one does not show up in the other. Being asked again in the home-screen app is a second sign-in, not a compatibility problem; Home-screen web app vs Safari tab explains the split.
5. Write to support with the two addresses. Send the locked address, the website address you entered and what you saw to contact@pwalock.com, never a password, for the site or for PWA Lock. A wrong address or a moved login is something we can point out; a provider that returns only to the address it was given is not.

What PWA Lock does not do about it

The limits, stated plainly:

• It does not rewrite the site's JavaScript beyond replacing the exact original address, so a script that compares hostnames or calls another subdomain keeps doing so, and it does not complete a sign-in flow on its servers while acting as you.
• It does not remove the site's security headers, so a strict Content-Security-Policy can block PWA Lock's own script. A page that loads without it will not relock when you switch away; the unlock still expires after 15 minutes, because the server enforces that limit.
• It does not replace the site's own login or restrict the original address, which stays reachable for anyone who has its login; PWA Lock is a gate on the locked address only.

If your site lands in the rows marked No, PWA Lock is not the right tool for it, and we would rather say so. Can you password-protect a website on your iPhone? compares the other routes to a password in front of one site, including Apple's built-in options.