Secure REST API and Single Page App by using external OAuth 2 Authorization Code

Firstly, and to be very clear, OAuth 2 is not an authentication protocol. If you wish to know the identity of the user, there are other protocols designed to solve this problem, such as OpenID Connect. If you intend to use OAuth 2 for the purpose of authorizing access to your protected resources, continue reading.

To answer your direct question: you appear to be using the Authorization Code Grant flow:

 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

This flow is optimized for confidential clients: clients which can keep a secret from the end-user and any third-party that might be trying to gain access to the protected resources. In the case of a javascript application running in the client's browser, you cannot keep a secret - all the code is there and simply breaking into it with the browser's debugger reveals all the secrets.

Instead, there is the Implicit Grant flow, specifically optimised for clients like yours. The RFC even uses JavaScript running in a browser as its example of a client intended to use this flow.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+

You should read the RFC for details of how this flow works, but the general concept of the flow is to no longer require the use of an authorization code; instead the client is directly given the access code.

This comes with the drawback that when the code is no longer valid, the client must request the resource again - there is no way to "remember" the authorization grant for a client which is unable to keep a secret. This is an intentional decision made by the OAuth authors to improve the security of clients of this nature.