 <h3>Short Answer</h3> <p>Despite the presence of a redirect parameter, the access token will generate a standard 200 response, not a 301 redirect. Depending on how you issue and handle the request/response, you can preserve your state.</p> <h3>More Detailed Answer</h3> <p>According to <a href="http://tools.ietf.org/html/rfc6749#section-4.1.4" rel="nofollow">section 4.1.4</a> of the OAuth 2.0 spec document (RFC 6749), the response to an Access Token Request should be an "HTTP/1.1 200 OK".</p> <p>In other words, the server will not perform a redirect, meaning you can issue a request and process the response in the same scope (either in the client or server, whatever your situation), so your database user ID need only be in local memory.</p> <p>This is different from the Authorization Request, which is supposed to result in an "HTTP/1.1 302 Found" (redirect). See <a href="http://tools.ietf.org/html/rfc6749#section-4.1.2" rel="nofollow">section 4.1.2</a>.</p> <p>So why is the <code>redirect_uri</code> parameter required?</p> <p>According to <a href="http://tools.ietf.org/html/rfc6749#section-4.1.3" rel="nofollow">section 4.1.3</a>, the server must:</p> <ul> <li><em>ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical.</em></li> </ul> <p>In other words, the <code>redirect_uri</code> acts as a sort of secret or password which the server must use to verify the access token request. If the client fails to provide a <code>redirect_uri</code> parameter, or the parameter value is different from the original request, then the server must reject the access token request.</p>