Using multiple oAuth identity services simultaneously

Question

This question is somewhat acedemic in nature. While educating myself about the topic of Security via a Bearer Tokens for a back-end service that I am working on, and specifically about oAuth2, a few questions came up in my mind:

1. If you were to outsource the identity provider / authorization service, you create a dependency on that service provider. How much of a pain would it be to move to a new oAuth2 service provider?
2. What if the service provider "fails" (disappears from the internet or have their systems compromised or changes their policies in a way that is incompatible with your requirements, etc)

As a way of reducing dependency it occurred to me that I might be able to configure the resource server to check every request to have two tokens, from two different service providers, eg SP-A and SP-B.

To do that your [client's] users would have to "be registered" at both SP-A and SP-B. That would imply that during the sign-up process, users details would be submitted to and records created at both SP-A and SP-B.

Client developers will be impacted in that they need to develop their applications to register users with two oAuth providers, and must obtain Authorization codes from two providers. For end users the impact may be minimized, but if a client wanted to use users' existing OpenID IdPs to effect initial registration and sign-in authentication, the user would have to authorize TWO access to their data.

The one immediate benefit would be that you could then set a global flag in the back-end for each of SP-A and SP-B, to ignore/bypass that provider, should you need.

You could also use different policies, eg require a valid token from all oAuth providers, or from at least one oAuth provider, etc, depending on your requirements.

Of course one would always still have to check an Authorization Providers' credentials, track record, etc and try to evaluate the risks.

Answer 1

I'm not sure what you mean. Here are my two best guesses:

• OAuth for authorization

  OAuth allows a third party (you) to access a user's protected resources from a resource server (probably an API) after gaining authorization through an authorization server (the OAuth provider).

  The OAuth provider is most likely the same organization that runs the resource server. If the organization disappears from the internet there's really no point in having a different provider to gain authorization to a non existent resource.

• OAuth for authentication

  There's also the chance that you are referring to using a third party identity service to authenticate users on your site.

  If that's the case, you don't need to tie to a particular service, just use OpenID Connect and let your users choose whatever provider they prefer.

  You can offer fast-track buttons for the most common providers, but you're not dependant on them.

  Ah, the joys of federated services :-)

Let me know if I completely misunderstood the question.

Answer 2

Client developers will be impacted in that they need to develop their applications to register users with two oAuth providers, and must obtain Authorization codes from two providers. [...]

Registering users with several oAuth providers and obtaining authorization codes from several oAuth providers is, as GnP already said, a non-issue in theory, since Open ID Connect gives you a standard protocol and even a standard discovery method for api endpoints. You write the code to get an authorization code and exchange it for an id and access token once, and run it against every compatible provider (your mileage may vary, though - I successfully deployed my code against Google's and Microsoft Azure's Open ID Connect implementations, but when I tried Yahoo, Yahoo didn't behave according to specs and didn't give a reason why it didn't...

Ignoring that caveat, supporting multiple Identity Providers instead of just a single one is basically just the difference between using a 1:1 relationship and a 1:n relationship in your user database - e.g. instead of attaching a single Open ID Connect subject identifier to each of your user entities, design your database backend to allow the attachment of an arbitrary number of them, and every time you want to support a new Identity provider, basically all you have to do (if it behaves according to specs) is to give your application the domain name where the IDP's discovery document resides.

but if a client wanted to use users' existing OpenID IdPs to effect initial registration and sign-in authentication, the user would have to authorize TWO access to their data.

I find authorization the harder problem to solve, but not for the reason you give, and I only have it because I have a preexisting user base with a well-defined set of access rights. My problem is this: Basically, each Open ID provider gives you a random string that identifies a user, but how do you match these strings to your user entities (and therefore, their authorization)? The subject strings you get from an IDP look completely random and you can't know them in advance, so if you have a known user base for which you have defined several access rights, how do you match an ID you can't predict to a given user entity in your authorization framework?

(The way I solved this is to use the E-Mail address the IdP gives me as part of the id token as a unique, known identifier to link an IdP's subject identifier to my user entities the first time I see a new user authenticate, but in order for that to work, you must trust that the IdP verifies E-Mail addresses correctly - a bet I wouldn't be willing to take for every IdP out there).

So yes, allowing multiple identity providers does generate some additional work, but it's mostly in the setup of different trust models for different IdPs. In my case, I trust an id token from my primary IdP implicitly, and I'm accepting only a small set of other IdPs, whom I don't trust to provide me with verified information beyond the identity token's subject identifier, so for these, I need a second solution to the matching/authorization problem I laid out above.

If you didn't work with a pre-existing userbase, the way to solve the matching issue would be to allow a user to merge his multiple identities by linking them all to the same user account. You could do this by having him authenticate with one user account, and then, while he's authenticated, tell him to authenticate with his other Identity providers. Your application could then link all these identities together as belonging to the same person / user entity in your database.