Single Sign-On Implementation \ Backend integration
The OneAll Single Sign-On service provides a central server which all your websites and/or applications trust. The central server encrypts and holds the user's data and makes it available to other websites in your eco-system.
5. Synchronize your users' data whenever it changes.
Single Sign-On is an access control management method that is used to provide login access to various services using a central server - in this case your OneAll cloud storage. To exchange data between different websites, you need to push that data to the central server at some point in time.
When to push data to the central server?
Generally speaking you should synchronize the user data with your OneAll cloud storage whenever the data changes in your database. There are typically three use cases that imply pushing data to the central server:
- The user logs in with a username/password,
- The user creates a new account by filling out a form,
- The user updates his profile.
In each of these cases you should make a call to the OneAll API in order to synchronize the user data
- Send the user's data to the central server in order to synchronize the user record.
user_tokenfrom the received data and add it to your
identity_tokenfrom the received data and add it to your
What if the user connects using Social Login?
Whenever a user authenticates with a social network, our Social Login service sends back a
connection_token to the
callback script that you might have implemented when you integrated Social Login.
6. Start a new Single Sign-On session whenever a user logs in.
identity_token should represent the information of the user that is currently browsing your website. By
using this token you can start a new session which will contain the underlying user information. Whenever the user switches
to another of your websites, the data will be exchanged with that website.
The Single Sign-On session should be started when the user logs in, right after having obtained his
as described above.
identity_tokenrepresenting the the information of the current user.
Use the obtained
identity_tokento start a new SSO session,
Keep the generated
sso_session_tokenin the user's session data.
7. Destroy the Single Sign-On session when the user logs out.
Whenever a user logs out you should delete his SSO session. This will invalidate the cookies that have been set for that session and the user will no longer be logged in through SSO on other websites in your eco-system.
The Single Sign-On session should be destroyed when the user logs out, right before removing the user's session data on your website.
sso_session_tokenstored in the user's session data.
sso_session_tokento delete the SSO session,
You should now be able to synchronize your users' data and start or invalidate Single Sign-On sessions.