Why do sites such as Google / Youtube have a redirect to a login screen for their Single Sign-On systems. Is this an industry practice?
It is done mostly for technical reasons. For the same reason, the default mechanism for ASP.NET websites is to have a standalone logon page, with a redirect after a successful logon back to where the user was.
Embedding the logon form on every page, with no redirect mechanism, has several issues:
You are sending the logon form for every page, making every page longer (in terms of transmitted bytes of HTML data). A link to a logon page is much shorter.
If the logon form appears as a "togglable" small rectangle in the top right corner of the page, you don't have enough place for descriptive error messages on failed logon.
If the page itself has other forms, they must not have the same names of fields as ones used for the user name and the password field.
UX-wise, the difference between a standalone logon page versus a logon form in the corner of every page is not too big. Moreover, having a standalone logon page let you display additional information and have much more descriptive error messages.
Good question! There's actually a very big reason for the redirect.
Single sign-on works by forwarding the user to the authentication provider, which does the actual authentication. This login page is hosted with the provider. If authenticated, the provider sends the user back to the consumer with an authentication token/ticket.
The reason it has to happen this way is because the consumer does not have access to the underlying systems needed to authenticate the user, and shouldn't be allowed to receive the user's credentials either.
This is not a usability problem, it's for security.
From UX point of view, the better solution would probably be to use a dialog of embedded html provided by the 3rd party (ie. an html modal). The only reason why this is not possible is security. If the authentication dialog were running on the requesting site, then a malicious script on that page could steal your password, or authorize his own app in a hidden way.
Auth providers (google, facebook, etc.) could use an iframe on the site, that would prevent (at least on not very old browsers) from code in the host page to access the iframe (eg. to steal your password), but the vulnerability there is that the host page could overlay visual elements on top of the iframe to disguise it as something different (eg. hide requested permissions by the app putting a white square on top of it, etc).
Therefore, the only way to ensure the requesting site can't do anything malicious with your Google/Facebook/etc account is (unfortunately) a redirect (or a popup, which is worse).