SSO - Architecture - Working mechanisms

What is SSO?

SSO means Single Sign On.

Why SSO?

Using SSO is a method of sharing user sessions with multiple domains. For example: auth.com, app1.com, app2.com & app.com Use case: 1. User will land on any 1 site app3.com 2. User will login using login credentials 3. User will be authenticated in app3.com 4. User visits app[1/2].com 5. User should be logged in without asking for user credentials.

The above scenario can be achieved using SSO. Using SSO, user will be sharing session between associated sites.

Any Examples?

Google: After user logging-in gmail.com, visiting drive.google.com will make the user already logged in.

How it differs from oAuth?

With OAuth, you can authenticate a user at an external server and get access to their profile info. However you aren't sharing a session.

A user logs in to website foo.com using Google OAuth. Next he visits website bar.org which also uses Google OAuth. Regardless of that, he is still required to press on the 'login' button on bar.org.

With Jasny/SSO both websites use the same session. So when the user visits bar.org, he's automatically logged in. When he logs out (on either of the sites), he's logged out for both.

Workflow? - Need more clarity From my learning An auth service @9000 3 App servers 9001 - 9003 Auth server details added as environment variables in App servers. app server attaches its session in Auth server with expiration time When user fills login form and submits, user credentials will be validated a cURL request sent to auth server to verify credentials valid credentials will generate a cookie in client on each request cookie will be sent to server for session validation

Simple way of implementing it? -

Try this https://github.com/jasny/sso

Any Reference?

https://github.com/jasny/sso

Pros:

Isolation Individual server scalability Micro services architecture Session sharing between register app server seamless session maintenance Debugging Optimization Refactoring Each apps no need to aware of others existence. such as app1.com no need to aware of app2.com, app3.com. this provides isolation of services very effective way.

for example, gmail.com no need to aware of existence drive.google.com, or chat application. Authentication service alone will know about existence of other applications which is required other service. So the services are fully independently functional.

Here event driven architecture also can be implemented. once user logged in, auth service can publish an event and whoever/whichever subscribing login event, can let the user without requesting login again.

This will help let individual team to develop separate services, without knowing others existence. Maintenance will be easy for individual apps

Cons:

Over load on auth server Need high availability servers session maintenances over proxies Might be facing issues in LoadBalancers

Additional Information: Each http request from client will send cookies to server. That is the default behaviour. Using cookie free server for static content is best way for structuring content delivery.