You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 20, 2024. It is now read-only.
As we entering 2018, our software becomes more complex and its services become more ubiquitous. Let's use Google's SSO for example to illustrate the demand for a modern SSO:
A user can sign in with password once for both Gmail.com and YouTube.com
A user can go to Feedly.com or New York Times and use the "Sign-in with Google" to authorize third parties to access the user's data
A user can sign in with password on a mobile device to sync all photos or contacts from Google
A Google Home device can connect to multiple people's Google accounts, and read out their calendar events when needed
YouTube.com developers can use Polymer as frontend technology, and authenticate with YouTube.com backend to load the content via web services API
You might not realize the complexity of such system to support the modern use cases above until your system needs one, and you need to develop the support. Let's translate the above use cases into SSO technical requirements:
Support SSO across multiple domains
Support Password Grant (sign-in directly on the web), Authorization Code Grant (user authorizes third-party), Client Credentials Grant (Machine sign-in), and Implicit Grant (third-party web app sign-in)
Support distributed architecture, where your authentication server is not necessary on the same domain or at the same server as your resource servers
Web services API on resources server can effectively authenticate requests
No technology lock-in for authentication server, resource servers as well as client-side apps.
Support a seamless user authorization experience cross different client-side technology (Web, Mobile or IoT), and cross different first-party and third-party applications
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As we entering 2018, our software becomes more complex and its services become more ubiquitous. Let's use Google's SSO for example to illustrate the demand for a modern SSO:
A user can sign in with password once for both Gmail.com and YouTube.com
A user can go to Feedly.com or New York Times and use the "Sign-in with Google" to authorize third parties to access the user's data
A user can sign in with password on a mobile device to sync all photos or contacts from Google
A Google Home device can connect to multiple people's Google accounts, and read out their calendar events when needed
YouTube.com developers can use Polymer as frontend technology, and authenticate with YouTube.com backend to load the content via web services API
You might not realize the complexity of such system to support the modern use cases above until your system needs one, and you need to develop the support. Let's translate the above use cases into SSO technical requirements:
Support SSO across multiple domains
Support Password Grant (sign-in directly on the web), Authorization Code Grant (user authorizes third-party), Client Credentials Grant (Machine sign-in), and Implicit Grant (third-party web app sign-in)
Support distributed architecture, where your authentication server is not necessary on the same domain or at the same server as your resource servers
Web services API on resources server can effectively authenticate requests
No technology lock-in for authentication server, resource servers as well as client-side apps.
Support a seamless user authorization experience cross different client-side technology (Web, Mobile or IoT), and cross different first-party and third-party applications
The text was updated successfully, but these errors were encountered: