5

I implement SSO to integrate some web login mechanism to the centralized member system which is OAuth2 provider. And currently OAuth2 authorization works well.

However, I would like to implement much more smooth login methods by AJAX call. For example, user logged in web A and member system already. When user navigate to web B, the web B should call AJAX to member system to see whether user logged in or not? If user logged in, the web B should show user the logged in page.

I have studied some of OAuth2 article (I cannot find link now). They all do SSO by redirect to OAuth provider directly. However, I would like to use CORS AJAX call because it could provide better UX.

I read another discussion about the risk of CORS and SSO: Designing single-sign-on with JSONP/CORS?

But I cannot understand the selected answer.

There must be a control in place to prevent a malicious JavaScript client from falsifying interactions with the authorization server. If the URL is supplied as an argument within a CORS Ajax request, rather then checking the HTTP origin header, then a malicious client is permitted to lie about it's context.

The URL could be verified by CORS header Origin.

My opinion is that if OAuth2 Provider set CORS Origin correctly, it should be fine to support CORS AJAX login mechanism. Because cookie and CORS cannot access by cross domain and violate CORS Origin strategy, it would not suffer CSRF attack. Only need to worry about XSS.

I am not very confident about my opinions, that's why I post here. If you have any advise or find my error, please let me know.

[Update More Detail]
In member system, I would define CORS settings like this

app.use(cors({
   origin: ["http://weba.com", "http://webb.com"],
   credentials: true,
   methods: ['GET', 'POST']
}))

app.get('/sniff', (req, res)=>{
    if(req.session.user){ res.send("user login")}
    else res.send("not login yet")
})

In the webA,

xhr.withCredential = true
xhr.open("GET","http://member.com/sniff") => I can tell if user login or not.
鄭元傑
  • 151
  • 5
  • Interesting, can you add more detail about what will be sent in the Ajax requests? And what exactly happens if the user is authenticated vs. not? – multithr3at3d May 22 '18 at 14:00
  • Interesting question. Not entirely relevant but while studying CORS, I had also wondered about a system where one could just use postmessage API for sharing authentication information between consumer and provider with pages opened in different tabs or iframes. These unique use cases of CORS are not studied in detail I feel. – Shurmajee May 23 '18 at 11:26
  • Also, The last time I checked, specifying multiple origins in the access control allow origin header was not supported by all modern browsers that is why many implementation tend to use the wildcard which allows all origins. – Shurmajee May 23 '18 at 11:32
  • @Shurmajee Thanks for your comment. About the browser support, it's pretty nice in modern browser (include IE10). I think using postmessage API would couple webA and member system too deep comparing to AJAX. – 鄭元傑 May 24 '18 at 02:13

1 Answers1

2

Over and above the advantage of only having to deal with one user database, there are 2 important security benefits of using SSO:

1) The application should never see the credentials - thus removing some of the attack surface

2) since the browser redirects to the SSO site, the user can easily verify that they are supplying their password to the appropriate system under appropriate controls (TLS, HSTS).

What you propose seems to directly undermine 2, and, since the client will be pointed to the SSO by the application, your proposal indirectly undermines the first benefit.

symcbean
  • 18,278
  • 39
  • 73
  • Thanks for your answer! I have studied OAuth2 implicit mode is also sending access token directly to browser and implicit mode is also warned under minor leaking issue. I am wondering whether CORS AJAX call is under the same risk level as implicit mode ? It is the same, then I use adopt the CORS version. – 鄭元傑 May 24 '18 at 02:17