Styjun

My server gets a bearer token in the header like so: Authorization: Bearer <token>. Now I need to validate that token, and for that to happen, I need who issues the token. For example, a Google token would require me to validate it using a Google API, and a Facebook issued token would need me to validate it using a Facebook API.

So how can I tell where the token originated from? Perhaps I need another field in the header that specifies it's origin?

Since you are using multiple authorization providers, I guess you don't utilize scopes other than profile (to get user's identity). So I think you could use your own OAuth2 server that supports authentication using external providers (Google, Facebook). Then your application would deal only with access tokens issued by your OAuth2 server, which would also keep info about the user's identity. This solution has an added benefit that you could support users without a social network account - they would create a new account at your OAuth2 server.

Another solution is probably less elegant, but easier to implement. Create a rule, that before using an access token, clients must register the token at some new endpoint with information about the token issuer (Google, Facebook ...). Then you can keep the info about who issued which token. At this point, after validating the access token, you can also consider replacing the token for a session cookie that would be used later for accessing your API instead of the access token. This solution is stateful, which makes it harder to scale, but using cookies would probably make clients easier to implement (no need for token refreshing).

As you wrote, your can also require extra info about who issued the token. You could use a custom HTTP header or a token prefix for it. It's easy to implement and it would not introduce a state to your backend.

Maybe there are some more solutions. It's up to you to choose one that would suite your needs.

If you mean Authorization: Bearer <token> to be the Bearer Token Usage defined by RFC6750, then there are few options to consider.

If by any means the token (token sent in header) is a JSON Web Token (JWT), then your API can validate the issuer parameter in the JWT to identify the issuer. To use this approach, request sending client need to obtain JWT access tokens. Check with different providers about this capability.

If first option fails, then you will have to use a custom header to communicate issuer details. Access tokens by definition (other than when a JWT is used) are opaque, so your API has no way to derive issuer by looking at it. So your client will need to communicate issuer details.

Third option is to have a client registration prior allowing them to consume your API. Once registered, you can issue them an identifier which you can map the access token issuer. When the client make a request, you can ask them to communicate client information through for example a header. This way you restrict your API consuming capability for anyone who can obtain an access token.