What Happens After /auth_info? October 25, 2013 by Juan Maldonado customer profile data I decided to address a question that comes up often in Support: what happens after the user is authenticated through Janrain Engage? Our Documentation site has a very detailed description of how our social login technology works to communicate with an end user’s social identity provider to return data about that user. It’s definitely worth a read as it is quite descriptive of all that occurs. Besides understanding the technical details of how our product works (in a nutshell, it authenticates), it’s equally as important to understand what things it does not do: It does not store user data It does not create or maintain state on your website It does not authorize an end user to your system Who does these things? Not to put too fine a point on it, but you, the site operator/developer, do. We built our social login product with flexibility in mind. This is liberating, as it gives you ample flexibility to do these things or even to not do these things, and you can make these decisions based on the requirements of your site’s user authentication/authorization experience and the technical requirements of your site. The starting point of this decision process is the information returned by the /auth_info API call. As a side note, however, if you don’t feel you have the bandwidth to develop your own solution as described above, an upgrade to Janrain Capture, our profile data storage solution will do all of this for you such as store user data, help maintain state on your site and authorize an end user to your system. Four Basic Ways to Use /auth_info Besides storing user data, authorizing a user and creating and maintaining state, there’s a few things you can do with the data returned from the /auth_info response: Whitelist or blacklist certain email domains, or individual email addresses Most providers (Twitter is an exception) will return a user’s verified email address in /auth_info. You can run a check against the email address and decide if you want to authorize that user to your site. This check can be done by checking the email addresses against a list of blocked emails in an array. If checks by individual email address are too granular, you could also look at the domain of the email address and check it against a domain blacklist for exclusion. This is good if you’re having issues with users who seem to be coming in from the same spam domains. Conversely, you could also look at the domain of the email address and check it against a domain whitelist for sole inclusion. This is a fine option for integrations that require a company email address to sign in, like an intranet site. Use the accessToken and scopes returned from /auth_info to run API calls directly to the respective provider, or even a third party provider /auth_info returns access credential data that can in turn be used with the social identity provider’s own API to do more data mining. You can also use that data to run an API call on some third party services. For instance, trulioo.com offers a service that checks a user’s Facebook profile via an API call (which you can make using the accessToken value from /auth_info) to determine the likelyhood of that user being a real person. You can use this probability score to either exclude the user altogether, or simply store that score as part of the user record so you can keep an eye on their activity on the site. If you do end up running an API call on third-party services, be sure to read through the social identity provider’s own policies and make sure your privacy and usage policies reflect this third party exchange of data. Serve up content specific to the user’s geographical location/social identity provider Did your end user move? If they updated their LinkedIn profile with their new address, you’ll know right as soon as they log in to your company’s site. Oh, and they used LinkedIn to sign in? Maybe it would be a great time to let them know your company is hiring and you’d love it if they could share those open positions with their friends. Don’t authorize the user, but use that data to augment your traditional username and password sign-up experience Authentication in Janrain Engage doesn’t necessarily mean that you have to use that data to sign in your end users. You could keep your site’s traditional username and password setup, but offer the opportunity for your new users to fill out your sign-up form using the user data from their Facebook or Google+ profiles. No one loves filling out long forms online. Offering the ability to populate a long form with a couple of clicks of the mouse can help you drive engagement. Congratulations! You’ve made it to the end of a highly technical but hopefully enlightening blog entry. As you can see, the /auth_info API call provides endless opportunities for you to use the data collected at the point of authentication. Even if you don’t use any of the ideas presented, perhaps this will inspire you to create additional functionality of your own besides the standard authorization flow.