rfc6749 4.3 - Resource Owner to Auth Server direct communication?

Question

Background

I'm building an spa and mobile app that will communicate with a rest api. I'd like to run a separate auth server to manage users (resource owners) and think the oAuth2 4.3 Resource Owner Password Credentials grant makes sense for my application.

As described in the specification, the user (resource owner) is supposed to communicate directly with my rest api (client), and my rest api (client) is then supposed to communicate with the auth server.

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+

            Figure 5: Resource Owner Password Credentials Flow

However, I'd like to change that flow. I'd prefer that the user (resource owner) communicate directly with the auth server, receive tokens, and then use those tokens to communicate with my rest api (client):

                                                  +----------+
                                                  | Resource |
                                                  |  Owner   |
                                                  |          |
                                                  +----------+
                                                   v
                                Resource Owner     |          
                             Password Credentials (A)
                                                   |
                                                   v  
                                                  +-----------+
      ------------(G)-------- JSON -------------->| SPA / APP |
      |      -----(D)---- Access Token ----------<|           |
      |      |                                    +-----------+
      |      |                                     v         ^
      |      |                  Resource Owner     |         |
      |      |               Password Credentials (B)       (C) Access token
      |      |                                     |         |
      ^      V                                     v         ^
     +---------+                                  +---------------+
     |         |>--(E)--- Token Introspection --->|               |
     |         |                                  | Authorization |
     |  REST   |                                  |     Server    |
     |  API    |<--(F)----- Token Metadata ------<|               |
     |         |                                  |               |
     +---------+                                  +---------------+

      Figure 5: Resource Owner Password Credentials Flow (modified)

FYI Steps (E) and (F) are as defined in RFC 7662.

Questions

I'm wondering what your thoughts are on this design. I know it's a bastardization of RFC 6749 but I think it's better suited for my needs.

1. Is there a better flow as defined in RFC 6749 that would meet my needs?
2. Is there another specification, other that RFC 6749, that would better suite my needs?

I think the pros of my flow are:

• Doesn't require me to store passwords in the spa or mobile app
• Allows my users to communicate directly with the auth server for login / logout, etc. completely separating the concern from my rest api(s)
• Allows me to more easily add other rest api's (micro-services) without having to deal with user auth.

I think the cons are:

• Requires my auth server to be public facing
• Requires a few more steps
• Doesn't conform to the spec, perfectly

Answer 1

OAuth 2.0 consists of two protocol parts: how to "obtain" an access token from the Authorization Server and how to "use" an access token against a protected Resource served by a Resource Server.

The picture you've pasted from the spec just doesn't contain the leg of "using an access token" since that is generic across all grants; it just focuses on the leg of "obtaining an access token".

Your diagram puts both together in a single picture but you're mixing up the roles: the REST API is not a Client. The Client is your SPA. The API is the Resource Server. Your picture then represents a (full) standard OAuth 2.0 Resource Owner Password Credentials flow + the additional token introspection part.