Dear Google, Facebook, Twitter, etc.,
I've got a nice, ready-to-use Single Sign-On system on my website. I've implemented a couple of providers (Google and Facebook) and, during my interactions with users and developers online, I've come up with a short list of a few things that I see as things that are must-haves that you need to change about your services to make it easier and more sensible to integrate with.
First, I should be able to pass a couple of URLs to your server that will display two links on the page where the user authorizes access for my application. Specifically, links to Terms of Service and Privacy Policy documents. These are legal documents and, without them, they open up the possibility of legal liability for the service that you are providing authentication for. Not having them defeats the purpose of providing the sign in service in the first place. A Privacy Policy or similar document also affords the perfect location for users to see why I'm asking for the various bits of information from your service. I, not infrequently, run into users who want to know exactly what their information is going to be used for. It is a fair question to ask. Unfortunately, none of the service providers support displaying such information - they simply say what permissions are required by the requester, not what the information will be used for. Most remote auth is done via URL, so there isn't a lot of room for sticking the explanation of permissions into the URL, but passing a URL to the explanation is likely to work much better and should be relatively easy to implement.
Second, and this is mostly pointed at Twitter, e-mail addresses are a must-have capability even if it has to be requested via an extra "scope" option. There are a number of great reasons to have the e-mail address of the user (and some not so great ones). Over on the Twitter forums there are a couple of semi-active threads constantly getting new developers complaining about the lack of this feature and why they want it. There are some great explanations on why this is necessary. I can understand the stance of it being a privacy issue, but if the first issue above of sending along a URL to a Privacy Policy statement is addressed, this becomes less of an issue as far as privacy goes (hence the name "Privacy Policy" - it has "privacy" in the name).
Third, this is mostly directed at Google: Don't require an exact return/callback URL. The SSO Server passes the 'lang' parameter around as part of the URL because multilingual support is loaded really early on before the session is loaded so error messages and a correct header and footer can be served up correctly in case something goes horribly wrong. Cookies, IMO, shouldn't be necessary for passing that parameter around. However, due to the super-strict requirements of the Google account sign in handler, I had to write a hack to get around the issue. Your callback/return URL should just require, at most, domain and path, but does it really matter if you check it at all? A hacker would have to have the OAuth2 secret to do anything with the token and access of who can use the OAuth2 credentials can already be restricted by IP address to grant even more security. So why even store anything in the first place on your server? Just have the developer pass the callback/return URL along with the request (which is already done) and trust that it is valid. If the browser never returns due to a bad redirect, no harm done. If it does, then you and I know the token and secret and no one else. Also, the only way to store a SSO Server URL correctly is to use the Advanced options in Google OAuth2. I'm not sure what the logic there was with OAuth2 setup, but it is flat out wrong design when, in order to get to get basic functionality working, I have to click "Advanced Settings" links. What I'm trying to say is that it just doesn't make sense to validate the callback URL. So...don't.
Fourth, can you agree to come up with icon sizes that are consistent? It can be difficult finding an approved icon that fits the size I'm looking for that fits within your guidelines on use. Have a wide variety of icon sizes to choose from and, if you really want to be nice, a set of PSD files with vectorized versions so we can scale it ourselves.
Fifth, can you all agree on a consistent documentation scheme when it comes to setting up authentication? Forcing developers to sift through your mess of documentation is a hassle. From a developer's perspective, you aren't special - you are a hassle, so figure it out. Google is the worst here with documentation that is as clear as mud on which is the preferred user auth method.
Finally, this is directed mostly at Facebook, but is applicable for everyone else: Don't force developers to jump through hoops to develop for your platform. Specifically, don't make it impossible to sign up for API keys for allowing users to do basic auth using your platform. Facebook is the worst offender - they have an utterly nonsense process for signing up for API access.
If you know a developer at any of these organizations, pass this onto them. The Internet will thank you for it.
I've got a nice, ready-to-use Single Sign-On system on my website. I've implemented a couple of providers (Google and Facebook) and, during my interactions with users and developers online, I've come up with a short list of a few things that I see as things that are must-haves that you need to change about your services to make it easier and more sensible to integrate with.
First, I should be able to pass a couple of URLs to your server that will display two links on the page where the user authorizes access for my application. Specifically, links to Terms of Service and Privacy Policy documents. These are legal documents and, without them, they open up the possibility of legal liability for the service that you are providing authentication for. Not having them defeats the purpose of providing the sign in service in the first place. A Privacy Policy or similar document also affords the perfect location for users to see why I'm asking for the various bits of information from your service. I, not infrequently, run into users who want to know exactly what their information is going to be used for. It is a fair question to ask. Unfortunately, none of the service providers support displaying such information - they simply say what permissions are required by the requester, not what the information will be used for. Most remote auth is done via URL, so there isn't a lot of room for sticking the explanation of permissions into the URL, but passing a URL to the explanation is likely to work much better and should be relatively easy to implement.
Second, and this is mostly pointed at Twitter, e-mail addresses are a must-have capability even if it has to be requested via an extra "scope" option. There are a number of great reasons to have the e-mail address of the user (and some not so great ones). Over on the Twitter forums there are a couple of semi-active threads constantly getting new developers complaining about the lack of this feature and why they want it. There are some great explanations on why this is necessary. I can understand the stance of it being a privacy issue, but if the first issue above of sending along a URL to a Privacy Policy statement is addressed, this becomes less of an issue as far as privacy goes (hence the name "Privacy Policy" - it has "privacy" in the name).
Third, this is mostly directed at Google: Don't require an exact return/callback URL. The SSO Server passes the 'lang' parameter around as part of the URL because multilingual support is loaded really early on before the session is loaded so error messages and a correct header and footer can be served up correctly in case something goes horribly wrong. Cookies, IMO, shouldn't be necessary for passing that parameter around. However, due to the super-strict requirements of the Google account sign in handler, I had to write a hack to get around the issue. Your callback/return URL should just require, at most, domain and path, but does it really matter if you check it at all? A hacker would have to have the OAuth2 secret to do anything with the token and access of who can use the OAuth2 credentials can already be restricted by IP address to grant even more security. So why even store anything in the first place on your server? Just have the developer pass the callback/return URL along with the request (which is already done) and trust that it is valid. If the browser never returns due to a bad redirect, no harm done. If it does, then you and I know the token and secret and no one else. Also, the only way to store a SSO Server URL correctly is to use the Advanced options in Google OAuth2. I'm not sure what the logic there was with OAuth2 setup, but it is flat out wrong design when, in order to get to get basic functionality working, I have to click "Advanced Settings" links. What I'm trying to say is that it just doesn't make sense to validate the callback URL. So...don't.
Fourth, can you agree to come up with icon sizes that are consistent? It can be difficult finding an approved icon that fits the size I'm looking for that fits within your guidelines on use. Have a wide variety of icon sizes to choose from and, if you really want to be nice, a set of PSD files with vectorized versions so we can scale it ourselves.
Fifth, can you all agree on a consistent documentation scheme when it comes to setting up authentication? Forcing developers to sift through your mess of documentation is a hassle. From a developer's perspective, you aren't special - you are a hassle, so figure it out. Google is the worst here with documentation that is as clear as mud on which is the preferred user auth method.
Finally, this is directed mostly at Facebook, but is applicable for everyone else: Don't force developers to jump through hoops to develop for your platform. Specifically, don't make it impossible to sign up for API keys for allowing users to do basic auth using your platform. Facebook is the worst offender - they have an utterly nonsense process for signing up for API access.
If you know a developer at any of these organizations, pass this onto them. The Internet will thank you for it.
Comments
Post a Comment