Automatically trigger auth flow

Due to the CSRF protection being turned on/recommended, I can’t seem to figure out how to trigger an auth flow automatically (when someone accesses a url that’s protected). If I have a login link/button with a post action, it works fine, but I can’t seem to trigger it when someone goes to a protected url (i.e. http://some.domain/app).

Is this possible without removing CSRF protection and not having another page with a login button? I’d prefer the user experience of automatically triggering the flow.

Thank you!

Could you please provide more context for your question? It’s not clear why CSRF protection would prevent you from triggering the authorization flow.

If you are using Auth0.js you can use webAuth.authorize to do this.

If you are using auth0-spa-js you simply call loginWithRedirect as described here.

Otherwise you can redirect the user directly to /authorize.

Thanks for replying! I’m using Rails. By enabling the CSRF protection with the recommended omniauth-rails_csrf_protection gem. This gem, enables CSRF. But doing this requires a POST request, thus there is no longer a GET route I can redirect to. The only way to redirect is now through a button/link using data-method=“POST”.

I’m trying to redirect to login page without the user having to explicitly click on anything. They go to a protected page, if they are not logged in, it would redirect them to auth0.

Disabling omniauth-rails_csrf_protection works, but then you’re exposed to https://nvd.nist.gov/vuln/detail/CVE-2015-9284

This is an old thread, but I ran into it while investigating the same issue, so I thought I’d try to summarize my understanding for anyone who follows:

The Omniauth CVE is exploitable if the IdP itself has some kind of CSRF vulnerability which allows an attacker to log the victim in to the IdP as the attacker. So now the victim is (for example) logged into Auth0 as the attacker. If the attacker can get into this state, Omniauth supporting GET requests allows the attacker to, if the user visits a website the attacker controls (likely the cause of logging into the IdP in the first place), make a GET request to https://mysite.example.com/auth/auth0. Since the victim is already logged into the IdP (Auth0 in our example), Auth0 will immediately redirect back to your site’s callback (https://mysite.example.com/auth/auth0/callback for example) and your site will issue a session token. Now any actions the user takes (or the attacker takes if there are further CSRF vulnerabilities) will be done in the attacker’s account.

So the threat model (if I’m understanding correctly) requires this as part of a chain of CSRF or other exploits, including and especially in the IdP. This is all about incorrectly using a vulnerable IdP to get into your app.

To summarize Rails’s CSRF protection: If you have to start the request using a button click in your app, then any remote requests from the attacker can’t do anything. And if the attacker tries to do the POST through an ajax call or whatnot, Rails on the way back will detect that the CSRF token from the IdP doesn’t match the CSRF token in the encrypted session cookie, and will block the request.

So you must introduce a page on your site with a button click which starts the Auth0 OAuth2 Authorization flow dance in order to be safe against this vulnerability. You cannot seamlessly redirect and not be vulnerable, since that’s the core of the vulnerability.

With all that said, let’s look at the actual threat model and the way we expect to use Auth0 in our applications. When you aren’t using Auth0, you generally have one cookie that is scoped to your app which determines login. So if you aren’t logged in, you go to a page, which blocks this case. If you are using social login directly in your app, you usually have a page which kicks off (often) one of several social login options. And since it is a remote site (Google, Facebook, Twitter, whatever), it makes sense to the user that they have to click a button.

However, we’re usually using Auth0 as a transparent replacement of what would usually be an in-app login system. This means that we’re trusting Auth0 pretty deeply. I don’t think it’s necessarily a wrong call to say that yes, a vulnerability in the Auth0 IdP would result in a further vulnerability in my site, but that’s the risk I’m taking using this in general, and I’m willing to accept that. If this is your answer, you need to turn on GET requests again with something like the following in an initializer:

# I'd love to find out if there is a way to scope this to only one strategy.
OmniAuth.config.allowed_request_methods = %i[post get]

I could also totally see someone deciding that they have a somewhat different threat model and introducing an interstitial button click is worth it. In that case, you probably want to set a session variable with a redirection URL, bounce the user to the interstitial, and then when they come back from Auth0, redirect to the location in the session variable.

I hope this is useful for someone in the future…

1 Like