Hello,
I am really excited about your framework and articles, but I am curious, how auth0.getTokenSilently() is protected from CSRF? Why including similar iframe to malicious website will not reveal a code and a token afterwards to the attacker?
Is it achieved by specifying targetOrigin for postMessage command in the /authorize endpoint response?
Best regards,
Nikita
Hey there!
Thanks for raising that question. I will reach out to our security team to find out more about that!
Hey again!
I placed an internal ticker for it to our security team. Once I have a response from them I will share it here. Thank you!
Hello Konrad,
Thank You very much for the reply!
Best regards,
Nikita
Just got the response from our security team.
When setting up the client that will be used for the auth0-spa-js in the Auth0 Dashboard, entries to the “Allowed Web Origin” and “Allowed Callback URLs” are needed.
auth0.getTokenSilently() sets an iframe and sends a request to /authorize. The important bits here are response_mode=web_message which indicates that the response will be for a postMessage instead of a redirect and prompt=none (no user interaction).
When Auth0 receives this request to /authorize, it verifies that the {{redirect_uri }} parameter matches an entry in both the “Allowed Web Origin” and “Allowed Callback URLs”. If the check is successful, it will return 200 HTTP.
In case of 200 OK, the /authorize response is HTML containing a JS script where the win.postMessage(authorizationResponse, targetOrigin) will take place. The targetOrigin suggests that only a window from the given origin will get the message. This targetOrigin contains the value of the redirect_uri that Auth0 checked you have registered. When the postMessage function will run, the browser will check whether the targetOrigin matches the recipient window’s origin. If it doesn’t, the postMessage will fail.
This link explains nicely how the targetOrigin protects against such attacks: Window.postMessage() - Web APIs | MDN