Imagine a widget (let's say it's written in React or some front end framework) that is able to sell your product. It makes API calls to your server to place orders, collect information about the customer, etc. Since the user is logged on, the widget can securely call your APIs using a Bearer token that was issued by your IDP when the user logged on.
Now, imagine you want to embed that same widget on a partner's website, so they could also sell your product along with their own product. This might be similar to buying an extended warranty during Amazon checkout or what not.
In this case, you would need a way to securely call your own APIs, but the user isn't necessarily signed on to your server nor do they necessarily even have an account. However, the partner knows who they are (at least their email address) and you trust that partner.
What's needed is a way for code hosted by a partner and running in a web browser to securely call a set of APIs securely under the context of the logged on user. I'm looking for any industry norms or best practices to implement something like this. We're running Auth0, and I believe the partner is as well (if not, we can assume it's a similar IdP that implements various OAuth workflows).
Some ideas I have in mind:
The idea here would be for the widget to pass along the partner's JWT token, which would include the user's email and what not. We'd configure our APIs to trust any tokens signed with that issuer using their public key. It would be as if we accepted tokens signed by our partner as if they were our own.
Pros: Probably pretty easy to implement.
Cons: I'm pretty sure any DevOps/SecOps engineer would absolutely hate this idea. Sharing access tokens with us widens their threat landscape, and they'd need to trust us never to do anything malicious with their user's tokens.
The idea here is the partner website would call some sort of API on our site from their server, passing in some sort of API key or maybe a client id and secret. This API would accept user information such as the user's email, and we would return back a JWT token that could be used for widget API calls for that user.
Pros: This should be pretty secure, since the tokens could only be used for the widget and nothing else.
Cons: It would require our partners to write backend code. Ideally, we'd like a pure "drop this in your website and go" approach. It would also require us to write those APIs and generate access tokens.
This is the one I know little about, and perhaps an Auth0 expert could chime in. I believe the idea would be for the widget to call the partner's IdP and initiate a login workflow with our IdP, and eventually get back a JWT token valid on our system. It would be similar to a "Sign in with your Google account" button, and we could easily create a user account for them on the fly.
Pros: No backend code required and also very secure.
Cons: Potentially a lot of IT work setting up federation between our two IdPs (I've done a bit of Auth0 configuration and nothing is ever easy). I'm also not sure if this sort of thing requires the super enterprise expensive tiers of Auth0, and if both of us either have those or have the budget for those.
Any other thoughts on how to do this sort of thing, or perhaps there's an industry standard approach that is recommended so we don't have to reinvent the wheel. Thanks!
I think that the most standards-based approach would be to use federation, but in a slightly different way than you describe.
The problem that you're trying to solve is this:
I think this should work like this:
This solution has the drawback of the user being redirected a couple of times to different servers. However, the user wouldn't have to do anything, just the browser will flicker a few pages and return to the partner website.
Other solutions that you mention here could be used in theory but they're not standard so you would have to put extra care in implementing them. E.g. in idea 2, if you used an API key and someone managed to steal it then she will be able to get access tokens for any user from you. Then she will be able to e.g. maliciously order things for users who didn't want to place the order and who would maybe have to pay for it now. Remember that the attacker will be able to do all the operations that the widget is able to do (and this is only if your APIs properly implement authorization checks).