Authentication & Authorization for multiple separated APIs

Architecture Overview: Single Authentication Server and a separate API for each group of users, that can access their API through multiple SPAs with SSO feature. Let’s say we have three APIs A, B and C and three users for every container (A1, A2, A3, B1, B2, ...). Each of these users should only have access to their corresponding API. So e.g. user B1 can only read/write with API B. Thoughtprocess: I read the documents about OAuth2 and OpenID Connect for authentication and authorization and I'm not sure if I understood this Framework correctly. In this protocol flow is a Resource Owner mentioned that I wouldn't need for my use case, as each user knows which API they have access to when they register. So I came across the following Refresh Token flow in the same document which would suit my thoughts better, where no Resource Owner is present. Given these are authorization flows only (?) and I'm missing the authentication part I checked OpenID Connect, but I thought of changing the native authentication mechanism of a webframework I would use would be more suitable given I know everything about the authorization part when a user registers as stated before. Therefore I came up with the following authentication/authorization flow: Prerequisites: Authentication Server: * Registered User A1 (username+password) with access to a private key PrKA specific to API A * Registered User B1 (username+password) with access to a private key PrKB specific to API B APIs: * API A with a corresponding public key to PrKA * API B with a corresponding public key to PrKB SPAs: * Any SPA that consumes the APIs Flow: * User A1 logs in to the authentication server with username + password * User A1 receives an access and a refresh token created with PrKA * User A1 is redirected to API A and sends the access token to the API * API A can verify the access token because it is in possession of the corresponding public key * User A1 can log into API A with the user claim in the token and a corresponding user object in the database * Authorization for API internal access will be managed by the webframework * On expiring of the access token, issue a new one from the authentication server with the refresh token Given the tokens and keys will be securely stored and transmitted (this would be my next question), would this brake the intentions of the OAuth2 framework or would it make the flow even insecure?
http://dlvr.it/RzmybK