Are these standard OAuth2 flows? (what are their names?)

Question

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.

1. Customer's app authenticates with us, passing their client_id and client_password. We return an access_token.
2. Customer's app passes the access_token in an Authorization header on all future calls.
3. Additionally, where the call is performing an action on a users behalf, they also pass a username in an Authorization header.

Notes:

• 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.

1. Customers' app is already authenticated from Flow #1, and has an access_token
2. Customers' app server calls our platform, with their access_token, and a username. We return an access_token for use for that user.
3. Customers` app serves this token to their client.
4. Customers' app client calls our platform, passing the access_token in an Authorization Header.

Questions

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?

Answer 1

your first flow looks like the OAuth 2.0 Client credentials grant. This is where two servers trust each other. The credentials are about the client, not the user, so the part about passing user info and acting on behalf of the user is not officially supported.

For flow #2, you probably want to use the Authorization code grant. The user would first authenticate to the customer app server and then get an authorization code it would also exchange this code for an access token. The access token would be passed to your application which you would then pass via back-channel to the customer app to verify the user authorization and identity.

We produce a service to enable apps to do this with very small modification. You can find out more at: http://www.assurebridge.com/our-products/mobileconnect/

Thanks,

Oleg

Answer 2

I've never seen the following parts of your flow:

1 - adding user-name to the auth-token given by the flow

2 - sending the token to the non-orriginating party

Not to say these could not be done, but your question is are they standard, so I am answering based on what I've seen working with various APIs.