OAuth 2: separating resource server and authorization server

OAauth2 framework docs : https://www.rfc-editor.org/rfc/rfc6749

(A) The client requests an access token by authenticating with the authorization server and presenting an authorization grant.

(B) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token.

(C) The client makes a protected resource request to the resource server by presenting the access token.

(D) The resource server validates the access token, and if valid, serves the request.

(E) Steps (C) and (D) repeat until the access token expires. If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.

(F) Since the access token is invalid, the resource server returns an invalid token error.

(G) The client requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.

(H) The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and, optionally, a new refresh token).

Your alternate scenario is probably what you want to go with: if you really really want to separate your flows out, you could try something like this:

1. user requests authorization from auth service on behalf of service with grant_type=code
2. auth service realizes user is not logged in: redirects to web application with a request parameter asking the web server to send user back.
3. web app stores request parameter, then asks for username/password
4. web app POSTs credentials to auth server (grant_type=password) and receives an access_token.
5. the web app stores the access_token in a session
6. the web app generates a signed token capturing the user id and redirects back to auth service with signed token as request parameter
7. the auth service parses signed token, extracts user id, displays allow/deny form
8. user is redirected back to client app with authorization code present
9. client app POSTs code to auth service (grant_type=authorization_code) and receives an access_token
10. client GETs resources from the resource server passing (w/ Auth header)

[http://alexbilbie.com/guide-to-oauth-2-grants/][1] Try visiting this for more clarity too.

As previous author said, password grant is used only if you the belong [SPA] or mobile app belongs to first party Like logging to gmail directly . GMAIL is part of google page/app,

ii) To get token from authorization server for code [ granttype=code] should happen from backend and not from browsser backend channel communication]

Check out OAUTH2 IN ACTION book - Manning publications, one of best writeup till now about oauth2