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.
Conclusion
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
