{"action":"opened","issue":{"url":"https://api.github.com/repos/networknt/light-oauth2/issues/101","repository_url":"https://api.github.com/repos/networknt/light-oauth2","labels_url":"https://api.github.com/repos/networknt/light-oauth2/issues/101/labels{/name}","comments_url":"https://api.github.com/repos/networknt/light-oauth2/issues/101/comments","events_url":"https://api.github.com/repos/networknt/light-oauth2/issues/101/events","html_url":"https://github.com/networknt/light-oauth2/issues/101","id":328791570,"node_id":"MDU6SXNzdWUzMjg3OTE1NzA=","number":101,"title":"OAuth 2.0 SSO with JWT requirements","user":{"login":"stevehu","id":2042337,"node_id":"MDQ6VXNlcjIwNDIzMzc=","avatar_url":"https://avatars0.githubusercontent.com/u/2042337?v=4","gravatar_id":"","url":"https://api.github.com/users/stevehu","html_url":"https://github.com/stevehu","followers_url":"https://api.github.com/users/stevehu/followers","following_url":"https://api.github.com/users/stevehu/following{/other_user}","gists_url":"https://api.github.com/users/stevehu/gists{/gist_id}","starred_url":"https://api.github.com/users/stevehu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/stevehu/subscriptions","organizations_url":"https://api.github.com/users/stevehu/orgs","repos_url":"https://api.github.com/users/stevehu/repos","events_url":"https://api.github.com/users/stevehu/events{/privacy}","received_events_url":"https://api.github.com/users/stevehu/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-06-03T01:49:53Z","updated_at":"2018-06-03T01:49:53Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"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:\r\n\r\nA user can sign in with password once for both Gmail.com and YouTube.com\r\nA 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\r\nA user can sign in with password on a mobile device to sync all photos or contacts from Google\r\nA Google Home device can connect to multiple people's Google accounts, and read out their calendar events when needed\r\nYouTube.com developers can use Polymer as frontend technology, and authenticate with YouTube.com backend to load the content via web services API\r\nYou 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:\r\n\r\nSupport SSO across multiple domains\r\nSupport 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)\r\nSupport distributed architecture, where your authentication server is not necessary on the same domain or at the same server as your resource servers\r\nWeb services API on resources server can effectively authenticate requests\r\nNo technology lock-in for authentication server, resource servers as well as client-side apps.\r\nSupport a seamless user authorization experience cross different client-side technology (Web, Mobile or IoT), and cross different first-party and third-party applications"}}
{"actor":{"display_login":"stevehu"}}