By Juan Maldonado | Posted on October 25, 2013
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.
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.
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:
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.
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.
Managing identities is a central concern of every enterprise. Almost all businesses have employee…
From the barista who knows exactly how sweet you like your daily nonfat, caramel macchiato to the…
Recognizing your brand’s need for a customer identity and access management platform is an…