Minimally trusting the server and client in OAuth 1
If you model who's trusted with what in OAuth 1:
Any environment
- Can safely transport a presigned OAuth 1 request
- Can safely forward traffic
Only dev-trusted environments (server)
- Can safely have an app secret
- Can safely perform OAuth 1 signing (OAuth 1 requires an app secret, unlike OAuth 2 has PKCE (a process to get auth for clientside use that can be started from the client) so doesn't)
Only user-trusted environments (ideally just client)
- Can view API responses
it's clear that it's designed for server-side applications. You can't fire off a clientside auth request since you can't sign requests from the client, you can't do it with a server without trusting the server with your responses, and you can't make a traffic forwarder that can sign the request without being able to see the response because TLS is symmetric post-handshake.
However, you can sign a request on the server. You can just spin up a microservice dedicated to signing requests. Remember, signed requests can be safely publicized.
From there it's up to the client to send it from there. They could connect directly if CORS is allowed, or if not, use a traffic forwarder like epoxy-server or something else Wisplike.