Single Sign-On Implementation \ Backend integration

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

1. Send the user's data to the central server in order to synchronize the user record.
2. Extract the user_token from the received data and add it to your oneall_user table.
3. Extract the identity_token from the received data and add it to your oneall_identity table.

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.

1. Use this connection_token to retrieve the user's details,
2. Extract the user_token from the received data and add it to your oneall_user table.
3. Extract the identity_token from the received data and add it to your oneall_identity table.

6. Start a new Single Sign-On session whenever a user logs in.

The 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 identity_token as described above.

1. Generate the identity_token representing the information of the current user.
2. Use the obtained identity_token to start a new SSO session,
3. Keep the generated sso_session_token in 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.

1. Read the sso_session_token stored in the user's session data.
2. Use the sso_session_token to delete the SSO session,