Sign in with $OSMO

The necessary building block for authenticating and authorizing access to centralized applications complementary to osmosis.

Comment

Inspiration

As a DeFi degen, I was delighted to witness the launch of osmosis so much so that I am spending my nights and evenings re-distributing $OSMOs into the pools I am participating in. While the osmosis frontend is the necessary and effective building block for doing just that, it comes a bit short with respect to some more complex features around liquidity providing and efficiency of applying them. As a liquidity provider, I'd like to follow a certain asset allocation, e.g. allocating e.g. 50% of my holdings to $OSMO, and 25% each to $LUNA and $ATOM. Now with all the volatility involved, this is actually not a trivial process for a human to efficiently converge to exactly that on a daily basis. Having that in mind and as a practical problem every day, I came up with the idea of building an additional frontend for managing and executing a certain strategy on osmosis. Plot twist: Early on in the development process however, after finally having made IBC run locally (🙈), did I acknowledge that I have to persist user specfic data additional to the data we have in osmosis-1. This inspired Log in with $OSMO 👇

What it does

Log in with $OSMO is the necessary building block for authenticating and authorizing access to centralized applications complementary to osmosis. It is a OAuth 2.0 compliant server that uses osmosis-1 as the Identity Provider and a user issued transaction in it to authenticate users. Developers who build on top of osmosis can use **Log in with $OSMO` by implementing e.g. OpenID Connect to leverage the OAuth Authorization Code Flow for authenticating requests to their app.

How it is built

Log in with $OSMO is backed by a cloud native OAuth 2.0 and OpenID Connect server, for the basic OAuth dance and ultimately issuing jwts to application clients. The authentication interface on top of that is a server side rendered node.js application. (It can not be only a Single Page App, there has to be a server-side component with access to the OAuth server.) The user interface implements the wallet connection as well as means for the user to sign an actual on-chain transaction to provide a proof of authenticity.

The demo application is a simple client side application fronted by a reverse proxy implementing OpenID Connect for enforcing authenticated access. For unauthenticated users, requests towards https://rebalance.diffusion.zone will be redirected to https://auth.diffusion.zone, providing above mentioned means for authenticating. After successfully doing so, the user is redirected back to https://rebalance.diffusion.zone with a nice and fresh session cookie set. Subsequent requests by the user to e.g. https://rebalance.diffusion.zone/api will be picked up by the reverse proxy and get enriched by adding the users jwt (Access Token) as the Authorization header for requests passed to upstream services. Upstream services, trusting the JSON Web Keys of the above mentioned OAuth server, can now authenticate requests and authorize actions given the jwt at hand.

Log in with $OSMOS is built extensible with respect to addition of new OAuth Clients. New clients can be added by submitting the OAuth Client as a kubernetes manifest complying to the spec like the one for rebalance.diffusion.zone. Merged PRs will be picked up by the underlying kubernetes clusters GitOps setup.

Challenges ran into

  • It's not easy to run a osmosis fully sync a new node on mainnet. I ended up having to switch from older to newer versions of osmosisd with increasing block height. I get why this is happening, but I think we can improve on documentation there :). I did also not get state sync running on mainnet, regardless of the seed and peer list.
  • This is not only osmosis specific, but it was quite difficult to get IBC up and running locally. I intended to have osmosis running locally with faster reward cycles for making my strategies testable in a speedier way. While I managed to run osmosis, cosmos, and relayer locally, dockerized and composed, it was quite hard to find all the relevant documentation for doing so.

Accomplishments

  • Major: Log in with $OSMO allows for strong authentication, by signing an actual transaction, for centralized applications complementary to osmosis, allowing for a new class of applications to be built on top of it
  • Minor: I think I've found a slighly nicer way of manipulating the gaiad/osmosisd config files as a part of the build process. The whole sed setup omnipresent in the cosmos ecosystem for configuring gaiad inside of Dockerfiles is not really readable and maintainable imho

Lessons learned

  • Launching a full node is not trivial. The on-chain data comes with a history, which the latest binary might not be able to understand
  • It's not so easy to setup IBC locally, but you will definitely need a relayer
  • There is quite a learning curve involved wrt. the REST APIs exposed by nodes in the network. While we do have a nice swagger documentation for cosmos rpc, it wasn't immediately clear to me how to properly write queries for transactions.

What's next?

I think it'd be nice to explore how Login with $OSMO itself can become less of a central party. While in my opinion it's fine for centralized applications to exist complementary to decentral ones, it'd be nice for the authentication system itself to be trustless. Furthermore, I'd like to investigate how Login with $OSMOS can develop into the direction of becoming a platform such as Auth0 to empower developers of the ecosystem to jumpstart work on complementary applications to osmosis. Working title: auth3.

Built With

Share this project:

Updates