I'm implementing an OAuth 2.0 authorisation server using the Authorization Code flow (i.e. users will authorise client apps to connect to our server). The auth server is the same as the resource server and it runs Node.js. The resource server has an existing client side application that users will use to sign in which is written in Angular and all client-server communication is over AJAX.

This poses a problem with the standard flow which requires an HTTP POST to the authorization endpoint which then redirects to the client's redirect URL. If I do this post over AJAX then the redirect will be lost as an AJAX request can't redirect the user. If, on the other hand, I do it as a form POST then it takes the user out of the Angular app which leaves them in a weird place if there were any errors during the request (e.g. database is down).

My solution is to modify the server authorization endpoint so that instead of returning the redirect URL in the Location HTTP header, it returns it in the response body. The Angular app can then access the value and do the redirect using window.location (assuming no errors).

My (admittedly incomplete) reading of the OAuth 2 spec seems to suggest that this is permitted:

HTTP Redirections

This specification makes extensive use of HTTP redirections, in which the client or the authorization server directs the resource owner's user-agent to another destination. While the examples in this specification show the use of the HTTP 302 status code, any other method available via the user-agent to accomplish this redirection is allowed and is considered to be an implementation detail.

I would like to understand what the security implications of this change are, particularly with reference this exchange.

  • 2
    hueniverse.com I'd suggest you go there and read that. That's the guy that made oauth 1.0, and was the lead person on 2.0 until he realized "Wait a second...". Commented Oct 9, 2015 at 16:15
  • Seems very similar to something I just answered today. security.stackexchange.com/questions/102274/…. But not exactly the same so, if you still need further explanation, I will write an answer.
    – Gudradain
    Commented Oct 9, 2015 at 18:55
  • @RobertMennell interesting read, thanks. Sadly we're interfacing with an enterprise organisation and have no say over the protocol used.
    – Tamlyn
    Commented Oct 12, 2015 at 9:17
  • @Gudradain Your last paragraph sounds relevant but I'd appreciate if you could explain why HTTP redirection is essential.
    – Tamlyn
    Commented Oct 12, 2015 at 9:18

1 Answer 1


Your question is very confusing as it's not clear who you really are or think you are... So, let's revisit the OAuth2 protocol.

The roles

OAuth defines four roles:

  • resource owner : An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

  • resource server : The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

  • client : An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

  • authorization server : The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

If we take stackoverflow as an example, the roles would be

  • resource owner : Kinda you but more your browser (strangely)
  • client : stackoverflow
  • resource server : facebook
  • authorization server : facebook

Who are you?

You start by saying that you are the resource server and then you say the resource server is using node and angular.

I'm implementing an OAuth 2.0 resource server using the Authorization Code flow (i.e. users will authorise client apps to connect to our server). The resource server runs Node on the server and Angular on the client and all client-server communication is over AJAX.

It doesn't make sense. The resource server is basically a webservice that is called by other applications, the clients, in order to retrieve information. Why would you use angularjs which is built to create a web application in a browser when the things that will access it are other applications that have no concept of a browser at all.

Who are you really?

Random guess would be that you are the authorization server, or more specifically, in regard to your question, the authorization server mentionned in the section 1.3.1 Authorization Code.

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

Now back to your question...

Yes you can do it without any problem. More specifically, your authorization server can return the redirect command to the browser which will then redirect to the right page using javascript. It doesn't change anything in the flow so there shouldn't be any issue.

Where is the confusion then?

It's simply that AJAX doesn't work instead of the redirect but here it's not what you are doing. The flow goes like this :

  • client redirects browser to authorization server
  • authorization server redirects browser to client

A common non-working idea is that you could replace those redirect an AJAX request from the client javascript to the authorization server and get your authorization grant. It doesn't work because of the same origin policy and the users wouldn't have a chance to confirm the authorization grant. But it's not your case here so let's forget about that.


The javascript in a page is really just an extension of the server (when using https). The only difference is that it's a public part instead of a private one like the server. It's a public part because the user can see all the code and all the data. You can do nearly all your logic in the javascript code, which is what you are doing with angularjs.

The only parts that should never be in it are the things that the user should never know. For example, the client secret which is why the implicit (1.3.2) authorization grant flow was created. In your case, you don't process any information that the user should never know hence there is no problem.

Reference : https://www.rfc-editor.org/rfc/rfc6749

  • I can't see any problem with it either but was thrown by Jared Hanson's comments on Github. Thanks for the detailed answer. I've updated the question to hopefully clarify it a bit.
    – Tamlyn
    Commented Oct 15, 2015 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .