Single Sign-On

From i4a API Wiki
Jump to navigation Jump to search

About

This article discusses the concept of Single Sign-On and how it relates to i4a. It is important to understand that this article will only discuss the concept of a a 3rd party using i4a to provide a single sign-on or authentication mechanism. It does not cover the opposite approach, where i4a would use a 3rd party API to facilitate authentication for a customer. For assistance with that you would need to contact i4a support.


Background

Single sign-on allows you to have a 3rd party use your i4a membership database to authenticate users on a remote system or separate website. There are 2 primary components to this process. Authentication and user session "state".

  • Authentication. Put simple, authentication will accept a username/password combination and validate that against your i4a database. If successfull, a packet of details about the user will be returned, allowing a remote process to not only validate a user, but also set various variables on their end such as first/last names, email etc. Performing an authentication will *not* in and of itself actually log a user in on your i4a website, but rather simply performs a check and returns needed information if the user is valid and active.
  • Seamless Logon. If you would like your users to experience a seamless experience across multiple websites you would be interested in implementing a single sign-on. On the i4a end, this can be achieved by your vendor setting specific cookies which if properly set should allow your users to login on a 3rd party website and if they then transition over to your i4a website will not have to login again. It is important to note that in the other direction, if you wish users to be able to login via the i4a website and thus avoid logging in a 2nd time on a 3rd party website, the bulk of that work will need to be performed by your 3rd party vendor.