Extend CSRF token validity to nearly a day, and use simpler error message

[mnelson4]

Fix for issue AngellusMortis#420 by improving wording and extending CSRF validity timeframe.

• WordPress' CSRF ("nonces") last 24 hours as a frame of reference. Previous to this, django_microsoft_auth's default validity was just 5 minutes.
• The new error message for this problem does occur is more direct to non-technical users. It says login didn't work, what they did wrong (left the browser open for way too long, probably), and how to fix (refresh and try again immediately). The old message was technically right, but I think it only made enough sense to developers who already knew what the problem was, not average users with no idea what "state" was. Also, it said to try again later, when retrying immediately was possible. I think this new error message will mean a lot fewer support requests for site admins.

I'm using these changes as-is on a live site.

[AngellusMortis]

Thanks for the PR! I really do appreciate even if everything else is going to sound a bit harsh.

OAuth state is not CSRF. Wordpress does not have an OAuth provider out of the box so it is not a valid comparison (nor should Worldpress ever really be used for an example of "secure").

The OAuth state should only be valid for as long as it takes the user to login. 5 minutes is plenty long enough to log in. As you said though it sounds like users are leaving the page open for an extended period of time rather than actually logging in. So, I think the solution is that we need to not generate the state value until they have the intent to login. I think this is already possible based on another PR that was submitted a while ago.

We should instead change the URL that gets put into the frontend to to-auth-redirect/ instead. This is a URL that just redirects to the authorization URL. This will make it so the state is not generated until the user goes to log with Microsoft's OAuth service.

If you still think 5 minutes is not long enough to complete the login flow after initializing it, I think adding a configuration setting for the state should be added instead of increasing the default to super long value.

Some code references:

• Redirect view for authorization URL: https://github.com/AngellusMortis/django_microsoft_auth/blob/master/microsoft_auth/urls.py#L24
• Where the URL for the template is generated (replace this with a URL made by reverse for the view above): https://github.com/AngellusMortis/django_microsoft_auth/blob/master/microsoft_auth/context_processors.py#L53

[mnelson4]

Ya only generating the oauth state just before redirecting the user would be a better solution, in which case just a few seconds would usually be long enough (so a configuration settings probably won’t be necessary). As a WordPress plugin author and contributor, the comment about WordPress not being secure wasn’t was a little hurtful. But I do see you’re point about WordPress not being a valid comparison because this is oauth

[AngellusMortis]

the comment about WordPress not being secure wasn’t was a little hurtful

I do have to apologize for that. I just have never had the best experience with WordPress and well, it does not have the best track record on CVEs.