9

I am experimenting with third party login, using Twitter and Facebook.

After getting access token from these parties, and confirming its validity, I then issue my own JWT token that's used within my application cluster. The only thing I use the 3rd party token for is getting an email address and user id, I don't interact with the social network in any other way, except for revalidation. Basically it is just so that users don't have to fill in new password.

I have several services, each on a different subdomain. These services somewhat adhere to the philosophy of microservices, and each is responsible for the narrow scope of functionality (e.g. UAC, business entity repo, etc. )

The sole purpose of the JWT token is to decrease auth check complexity among the other services, which shouldn't be Oauth provider aware. I also don't want to identify which provider they chose in the publicly visible JWT.

I installed a third party (officially approved) SDK on the UAC microservice, with which I'm interacting through AJAX request.

EDIT: Updated flow, for better clarity

  1. From the presentation layer: require authorization URL from the UAC module. On the UAC module side, the SDK handles CSRF token creating, and sadly, storing as well (at least the FB SDK does). The CSRF token is set into the session.
  2. Redirect the user to FB auth page, the user authorizes, gets sent back to my presentation layer with a CSRF token to compare
  3. This is where the CSRF check SHOULD happen, but the original token is not set in the current session, instead is in the UAC module
  4. From the presentation layer - server-side: grab Oauth token and CSRF token, send it to UAC module
  5. This is where the CSRF check COULD happen, but server-server communication doesn't have the session. This is where I skip the CSRF check by tricking the SDK to accept whatever CSRF token just came in
  6. Validate the Oauth token, exchange for long-lived one, fetch users data, create user entity in my database, issue JWT, done.
  7. JWT is set from the Presentation layer - server-side with SetCookie. This cookie users HttpOnly and Secure ( but that's not really the issue here )

In simplest terms: I want to achieve the same functionality as regular Oauth with these providers, but I need to split the process among two subdomains. Neither of these should have a PHP session if possible, except for the brief moment of FB SDK forcing me to use one.

What I have tried so far: I changed the architecture a little, and instead of directly talking to the UAC module from javascript, I bounce the request through the server-side on the presentation layer, and in that session, I store the original CSRF token. When later the user comes back from the FB auth page, I can perform the check. I still have to trick the SDK on the UAC side, but that is after I verified the CSRF ( albeit not through the SDK itself ) Can I go ahead with this approach? Is this risky in any way, because I send the CSRF token between servers?

R1W
  • 1,617
  • 3
  • 15
  • 30
Slytherin
  • 141
  • 4
  • 2
    Which is the question? I don't fully understand which are the problem. Please, put numbers on your flow steps and mark from which you can jump and to which bypassing what. – OscarAkaElvis Feb 10 '17 at 13:57
  • Although your question seems a bit unclear, did you consider [sharing Cookie](http://stackoverflow.com/questions/18492576/share-cookie-between-subdomain-and-domain)s between subdomains? Wouldn't that save a lot of complexity on each layer? – Sankalp Sharma Feb 12 '17 at 13:57
  • I edited the question so it's more clear hopefully. @SankalpSharma I am already doing that, thats not the issue here. – Slytherin Feb 13 '17 at 15:44
  • @OscarAkaElvis Edited. – Slytherin Feb 13 '17 at 15:45

1 Answers1

1

Its not entirely clear what the actual question is here, but it seems related to CSRF, I will answer the question assuming its related to how best protect against CSRF.

I would recommend implementing the cookie attribute "sameSite" in strict mode [1][2].

SameSite is a 'newer' cookie attribute that's primarily designed to protect against CSRF style attacks. Setting the value to 'STRICT' ensures all of the HTTP methods are protected, i.e., if you set the value to 'LAX', GET requests will send the cookie, while 'POST' requests wont etc. It is suggested that 'LAX' is a balance, but this is somewhat subjective and requires context. Setting to 'STRICT' ensures the browser will never send a cookie other than from the origin.

[1] MDN Cookie Attributes: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies

[2] OWASP sameSite https://www.owasp.org/index.php/SameSite

Darragh
  • 1,102
  • 9
  • 15