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:
- 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?
- 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.