EPIC: Block Node Authentication (OAuth2)

[Nana-EC]

As a block node operator
I want to ensure authenticated access with paid usage on my streaming APIs
So that I can cover some of the costs of my BN instance

Basic OAuth2 Stages

Preview Give feedback

1. Basic OAuth2 Provider #613
   +0
2. Add OAuth2 to the Helidon gRPC endpoints. #614
   +0

Note: Basic OAuth2 Provider is identity only, no auth yet, just simple “trust what you tell me” information added to a token (i.e. takes account ID and creates token; no checks).

[jsync-swirlds]

Some detail (from a slack conversation and earlier meeting) regarding authentication approaches
We created this Diagram with @jsync-swirlds and @AlfredoG87 so it is easier to understand the flow of UX

Fredy's Explanations

1. OAuth Provider can be anyone the BN Trusts its tokens. But we will build our own.
   1. We won't reinvent all the wheels here, there are many frameworks that we can leverage including Helidon4 but there are plenty.
   2. So basically the OAuth Provider verifies the challenge and signs the token it issues, and the client either has or gets the pubKey of the issuer to validate the token and assert Identity.
   3. Since each BN can use it's own OAuth provider as it desires, it should be configurable, imagine a endpoint service that exposes the pubKey of the issuer that the BN Trusts. (also an standard in OAuth)
      • For a first version we may just lock to our own provider; we'll work that out during detail design.
   4. We will create our own Basic OAuth Provider as a standalone Java container (Deployed together with the BN using the Helm Chart).
      • No need of the portal support, completely standalone and no direct user interaction.
2. The challenge is a nonce, that expires rapidly, that the client needs to sign and return.
   1. How it signs it is up to the clients but they may use any tools available.
      • We may provide a Java and JS Example on how to consume the /challenge and /token endpoints of our Provider for clients to use.
   2. Initially the OAuth Provider should have 3 endpoints:
      • /challenge --> Client gets a challenge given an AccountID, challenge is unique and expires in X minutes.
      • /token --> Client sends the resolved challenge and OAuth Server issues a new token that expires in X amount of time.
      • /jwks --> OAuth exposes pubKey in this endpoint, BN Server uses it (probably at load time) to store the pubKey of the issuer that trusts.
   • All those 3 endpoints are simple and straight forward using a good framework (including JWT creation)
   • Verification on the BN we get for (almost) free using Helidon Security
     • It is plausible to have something very basic in a couple sprints.

Joseph's Clarifications

OAuth2 Detail

1. The OAuth provider is a container deployed with the block node, or possibly an in-process plugin. There is no separate server, and we don't recommend relying on a (separate) central provider (for several reasons).
   • We're trying to keep this as simple as possible to support our monetization, which means reducing what options we permit.
2. The entire focus of the authentication provider is to connect the user to their Hedera account; so it must be a signature with the Account key.
   • Certainly third parties might someday write a different monetization service, and implement some other setup, but this is what we're recommending for our monetization service.
   • The monetization service, like all others, is a plugin that may be replaced, or not even deployed, as desired.
3. Central OAuth2
   1. This would require every BN coordinate with, and rely on, a central server. It also requires that we build a central server, which is a lot more work than building a tiny, very focused, service that is deployed as part of the BN (likely a separate container, but could be an in-process plugin service).
   2. The hardest part is that the BN must communicate the account to the OAuth2 Provider because the BN creates the account when HBAR are transferred, so it is substantially more complex to have a completely separate and independent OAuth2 provider versus one that's closely associated (same process or at least same physical machine, with a shared volume via k8s) with the BN.
      • Fredy counters:
        Not necessarily, the way I picture is that the BN Trusts the OAuth2 Provider, so the Client goes to that provier and authenticates (in our case using its signature), then receives a token that contains his accountId (Hedera), BN receives token, makes sure is from the trusted provider and then the BN checks if that accountId has the funds... no need for the BN to ever talk to the OAuth2 Provider. The BN does creates an account when HBar are transfered, but that account stays inside the BN, when it receives a token that contains a certain accountId, just checks if it has an account associated with positive balance already created, otherwise returns appropiate error.
   3. Any centralization of authentication increases the centralization of the network, and that is generally considered a negative metric.

API Keys

1. API keys are effectively a password that never changes. Every security expert I know of argues against the use of API key for that exact reason, that they're eternal passwords. They suffer considerable risk of exposure in many places. Examples:
   • They're intended to be used by software rather than a person (so adding to codebases is a real risk), and the security of the Client software thus becomes much more critical.
   • They're communicated much more frequently than a password (every call rather than once per session).
   • Compromise is nigh impossible to detect until it's too late
   • They're not recognized as security elements as readily as, for instance, a private key or other cryptographic element.
2. To use an API Key we must build both the key issuance (which is probably a portal), and also must build the authentication code in the BN, because it's not built in to Helidon, gRPC, or other libraries we're already using. It's entirely possible that implementation for API keys is more work than OAuth2.
3. We believe the risk profile for a Block Node is significantly higher than most services using API keys (e.g. RPC relays or Graph query nodes), and warrants a more secure alternative. OAuth2 is widely used precisely because it strikes an excellent balance between higher security and complexity. We could certainly choose an even more secure option, such as signed requests (as the consensus network must), but that level of security and complexity appears to be excess to requirement at this time.