.gist width!auto!important!!.gist_file.gist_data max_height: 500px;max_width: auto. This is part 6 of a tutorial series by Ben Finkel that addresses the challenges, solutions and implementation of sound authentication. You will feel confident in your ability implement an authentication system, even if you have little to no background.
I introduced something I called “state token” during the previous tutorial, but didn’t bother to explain what it was or where its origins were. It is an OAuth 2.0 specification (RFC 6749: 4.1.1). Authorization Request.
RECOMMENDED. This opaque value is used by the client for maintaining state between the request/callback. This value is included by the authorization server when the client redirects the user-agent to the client. This parameter SHOULD be used to prevent cross-site request forgery, as described in Section 10.12.
This should be “strongly recommended”, as the state token is essential for addressing a vulnerability in the OAuth Grant flow, Cross-Site Request Forgery. This value will be required by most OAuth providers when you request a Grant Authorization. RFC 6749 provides a brief description of CSRF attacks and how to protect yourself from them. However, it is not very clear. Before we continue, I’d prefer to talk you through it. We can also learn more about the secondary use of the state token — remembering application state!
Learn how to become a security expert with SPOTO’s Cybersecurity Training
Get started in Cross-Site Request Forgery Training (CSRF).
One of the most obvious ways to attack the OAuth dance is at the beginning, during Grant Authorization.
The Grant Authorization process is where the user’s browser is redirected first to the provider’s endpoint, then back to the consumer app. This redirection is important as it represents a decoupled call/response. An HTTP request and response is used to accomplish tasks such as exchanging an authorization code for access tokens. An actual redirect is required because the Grant Authorization process requires that the user be involved.
This creates an opportunity for an attack. The browser and server exchange tokens during a request and reply to ensure they have a continuous line-of communication. A redirect is a new line, so malicious attackers could hijack the redirection to their own ends. This is called a CSRF attack. This post explains how it might happen.
To stop this attack, we create our own code that can be tied directly to the Grant Authorization session. The provider receives the code in the state variable. However, the provider only echos it back to us in the redirect to our app. We can verify that the state token received by the provider matches the one we sent. This prevents CSRF attacks.
The following code is used to create a state token using two key variables in our example:
A private app-specific “key”, which I just created (you can use any value).
The current date/time.
These values are encrypted with SHA1 encryption to prevent them from being guessed. They are then base64-encoded to ensure they can be safely embedded into a URL query string.
You can also check the previous post to see how I include this value in my redirection towards the Grant Authorization endpoint. Also, I store it in a session variables so that it can be retrieved to verify.
Remembering Application State
The state token can be used for more than just protection against CSRF. It’s right in the name “state.”
Sometimes, users will be deep in our UX after filling out information or changing their settings.