In the following we sum up our argumentation for using certain OAuth 2.0 grant types in two scenarios and kindly ask the community to either agree with our argumentation or to identify weaknesses.
The overall goal is to protect an enterprise API using OAuth 2.0. For this use case of OAuth 2.0 we distinguish two scenarios:
Scenario A: The API is used by an application developed by a third party, e.g. an application available from an app-store that uses our API.
Scenario B: An in-house developed application which uses the API, e.g. a single-page web-application that uses a RESTful API.
We use a Gateway (which embeds a reverse proxy and an OAuth 2.0 client) in order to hide the internal API security mechanism and not to expose the Access Tokens to the public. The Gateway handles both dynamic routing and mapping between the sessions on the customer side and the Access Tokens on the internal side. Relying on cookie-based session management, allows us to benefit from already established session protection mechanisms and enables Single-Sign-On capabilities for different client applications. We use JWT Bearer Tokens to authorize the calls between the Gateway and the APIs.
In both our scenarios, the OAuth 2.0 client is under our control and can thus be considered as confidential.
According to our understanding, the two scenarios have different protection requirements:
- Scenario A: The application code is not under our control and may contain malicious components. We thus want to prevent the application from getting hold of any user credentials or Access Tokens. Using the Authorization Code grant type, the Resource Owner authenticates against our platform (redirected to the our OAuth 2.0 authorization server) and grants access to his resources.
- Scenario B: This time the application code is under our control, i.e. we know that the code does not contain malicious functionality. We can therefore trust the application to process user credentials reliably. As a consequence we propose to use the Resource Owner Password Credentials grant type. In this case the Resource Owner credentials are exchanged for an Access Token using a single request without requiring the Resource Owner to approve the access to the resources.
In both scenarios, the JWT Bearer Token does not leave our platform and is only used between the Gateway and the corresponding APIs, whereas communication to the user agent (typically the browser) uses classical cookie-based session management. As a consequence of this setup we enable session based Single-Sign-On capabilities on the user side, whereas we allow stateless API-design as it is required in modern architecture styles such as REST.
In a regular OAuth 2.0 scenario, both the Web App and the Mobile App would be OAuth 2.0 clients in their own right. Of course it is possible to do OAuth 2.0 between Gateway and backends as well, but it makes sense to use a standard protocol towards the Web App and Mobile App, especially since the latter is developed by a 3-rd party.
Weirdly enough your reasoning is completely correct and valid for the situation where the Web App and Mobile App are OAuth 2.0 clients. But for the situation where the Private Gateway is the OAuth 2.0 Client in a pure internal scenario, security considerations and standardization are actually less relevant.
So the question is: what type of authentication/authorization do you use for your Web App and Mobile App. Especially for the latter it is interesting to know how the communication between the Mobile App is secured and authenticated. I believe that leg begs for OAuth 2.0. Also the way in which the Web App presents the username password to the Private Gateway, and the way in which a session or token is maintained after that, begs for OAuth 2.0.
(But perhaps the picture is just a mis-representation and the text is what matters here)