Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question
1  
Can you suggest an alternative? (Real question, not being snarky.) –  Matt Sep 24 '12 at 16:40
    
@Matt some single sign-on providers allow the user to login via a modal. (Facebook connect works this way in some cases) –  Kroehre Sep 24 '12 at 19:16
    
If you don't mind, can you accept an answer? Thanks! –  Kroehre Oct 2 '12 at 4:20
    
Sure, thanks for helping out. –  brakes Oct 2 '12 at 9:22

3 Answers 3

up vote 3 down vote accepted

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.

  • Showing and hiding logon form on click requires JavaScript, and a specific version must be made for people with JavaScript disabled. The form must be also shown on failed logon (in order to display an error).

  • 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.

share|improve this answer
1  
ASP.NET's forms authentication doesn't really use a seperate login page for the same reason... this is just the simplest implementation for a login page. Single sign-on uses a redirect because it has to occur on a completely different domain. Having an extra form with 2 or 3 inputs isn't going to impact the response size very much at all. That's not correct about the form field names... as long as they are wrapped in separate form tags they can use the same field names. –  Kroehre Sep 24 '12 at 19:08
    
@Kroehre: Ok, reading your comment and your answer, I understand that I misunderstood the original question. For me, it was not about OpenID and similar mechanisms, but about the logon inside the same website, i.e. an ordinary, internal logon. –  MainMa Sep 24 '12 at 19:29

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.

share|improve this answer

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 still your password, or authorize his own app without 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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.