I'm developing a B2B platform, where other developers (our customers) will build shop-front style apps that leverage our platform.
We expose a REST based API which our customers either call directly from their app servers, or their own client apps can all, on behalf of their users.
Their apps are standalone, and they "own" the relationship with their users, including authentication.
From an end-users perspective, interaction with our application is transparent.
Also, our customers operate on our platform at an elevated level of trust. Given that they own the relationship with users (and simply use our platform akin to back-office processing), users don't have to grant them access to operate on our platform on their behalf.
Therefore, we've identified two standard interaction patterns for use with our API.
I'd like to implement as close to OAuth2 as possible, but I'm not sure these strictly conform to the existing flows.
Flow #1: Customers' app server to our platform
This is the flow for strict server-to-server communication.
- Customer's app authenticates with us, passing their
client_password. We return an
- Customer's app passes the
access_tokenin an Authorization header on all future calls.
- Additionally, where the call is performing an action on a users behalf, they also pass a
usernamein an Authorization header.
- The issued authentication_token is not bound to a single user. It allows them to act on behalf of many users (though limited to one per-call)
I suspect this is a variation of the "password" flow, but where the user's password is not required.
Flow #2: Customers' app client to our platform
This is the flow where a customers' app is communicating directly with our platform, rather than through their app server.
In this scenario, the user has already been authenticated with the customers app.
- Customers' app is already authenticated from Flow #1, and has an
- Customers' app server calls our platform, with their
access_token, and a username. We return an
access_tokenfor use for that user.
- Customers` app serves this token to their client.
- Customers' app client calls our platform, passing the
access_tokenin an Authorization Header.
Are these existing, standard flows within the OAuth2 spec? I've read it, and I don't believe either of them are described.
If not existing, are there similar flows we should be looking at, that still suit our requirements? Specifically:
- Customers' app servers can perform actions on behalf of the users
- Customers' app servers do not require new access codes for every user they wish to proxy
- Customers' clients / users can access our platform without directly logging in (but are still authenticated via their app server).
Are there issues with either of these flows that make them really bad ideas?