Intermediary systems invoking our API

[Leonardo Alexandre Ferreira Leite]

Hi,

my team is building an API with SSL two-way authentication.

We have a couple of partners that are going to consume our API.

We have designed our API in such way we identify the partner caller by the digital certificate used on SSL connection.

So each partner must have its own digital certificate, that is linked with an identity in our database.

Now the trouble.

Our partners are not in the TI business, so they will hire other companies to develop the systems that will actually consume our API. Let's call these hired companies as intermediaries.

Moreover, each intermediary will build a single system to be used by a couple of partners.

So we have something like partners p1, p2 and p3 using the system sA developed by intermediary iA, and partners p4 and p5 using the system sB developed by intermediary iB.

My company has no direct business relation with the intermediaries. So at first we would like to ignore them in our architecture.

Therefore, what we are currently asking from intermediary iA, for example, is "when your system sA invokes our API on behalf of p1, use a digital certificate specific for representing p1; when your system sA invokes our API on behalf of p2, use another digital certificate specific for representing p2".

It would be nice for us, but we are not confident that this is the right way.

Maybe we should identify the intermediaries in our system by the certificate on SSL connection and just let, for example, sA say "I'm invoking your API on behalf p1", given that we already registered that sA is allowed to invoke us on behalf of p1, p2 and p3.

Another path could be something like OAuth. But I'm not sure if OAuth itself would be exactly the path, since we are not interested in exactly authenticate the end user, but the partner that is invoking us (i.e. we do not need an identity for each end end user, but only an identity for each partner).

So I would like to hear of you what would be the best market practices for such scenario.

Thank you!

Leonardo Leite

[Alex Bowen]

Hey Leonardo, 

Have you checked out DreamFactory? You mention you're building an API - DreamFactory would be able to create the API for you, as well as provide security, SSO and OAth, amongst other things. You can also manage user permissions and roles which can help when working with other folks. 

I think this may be a solution for you? Feel free to check em' out: https://www.dreamfactory.com/features

You can think of DreamFactory as a middleware. 

Thanks, 

Alex

[Jørn Wildt]

I think both solutions work fine - either one certificate per intermediate or one per partner but stored at the intermediates.

I have seen a very similar public solution in Denmark where each partner registers a certificate with the central service and with this registration states both its own partner identity and the intermediate who is going to work on behalf of the partner - the intermediates then manages multiple certificates (one for each partner). Seems to work fine.

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Leonardo Alexandre Ferreira Leite]

Thank you so much Jørn! Your comment was highly valuable for our team!

Someone else know other real case like the one presented by Jørn?

--
You received this message because you are subscribed to a topic in the Google Groups "API Craft" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/api-craft/YfR4JzscF-4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to api-craft+...@googlegroups.com.

[Andrew B]

You don't need to discount OAuth just because you don't need actual user identity. OAuth deals in "resource owners", who are not necessarily people - they could be partners in your case.

Sometimes people equate OAuth with authorization code grant tha they are familar with ("Do you want to allow this app to post to your pages, access your email, etc.). But for your purposes you could instead go with the client credentials grant, which does not interact with an end user.

[Jørn Wildt]

OAuth is certainly also a possible solution. Just be aware of the problems with OAuth2 - see for instance https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ for a discussion.

Client certificates work well in a business-to-business solution as yours where various backend servers speak to each other. I would expect the tooling here to support client certificates out of the box (at least .NET does). I would also expect it to be much more difficult to use client certificates from a browser based solution (human-to-business solution). OAuth on the other hand works very well with browsers - and is probably more widely known by the average client developer than certificate handling is..

So assuming that your solution is a backend solution with full client certificate support, you have access to well educated developers and such a solution should be slightly more secure than OAuth2 I would choose client certificates.

Pick your choice :-)

/Jørn

--

[Leonardo Alexandre Ferreira Leite]

OK, so it's nice to know that OAuth is also good when resource owner is a system, and not only it is an end user. However, I didnot know that OAuth cannot be mixed with digital certificate (in the step the resource owner invokes the API giving permission to the intermediary). But indeed in our case I believe the digital certificate usage is already given.

Thank you guys!

[Jørn Wildt]

> However, I didnot know that OAuth cannot be mixed with digital certificate (in the step the resource owner invokes the API giving permission to the intermediary).

It seems as if you missed something (sorry if I am wrong): as Andrew said: "But for your purposes you could instead go with the client credentials grant, which does not interact with an end user." - so there need not be a step where "the resource owner invokes the API giving permission to the intermediary". See https://tools.ietf.org/html/rfc6749#section-4.3.

In addition to this Googl uses certificates for the client credentials grant (but not on the SSL/TLS level) in the form of Javascript Web Tokens - https://developers.google.com/identity/protocols/OAuth2ServiceAccount#authorizingrequests

/Jørn