Designing an authentication flow based on Oauth?

[weiwu.zhang]

At first, Oauth woudn't even cross my mind in designing blockchain-based authentication. oauth assumes a 3rd party identity centre point (we don't have one in blockchain); it is a authorisation protocol (not authentication protocol like OpenID) and that it relies on confidentiality (non-existent in blockchain nodes and services).

While reading Ethereum Foundation called out for a design based on Oauth I was puzzled for a bit, then I realised their side of reasoning. They most likely interviewed web2.0 developers and these people told them that FAANG wanted them to use oauth and now they want to use OAuth for Ethereum, where Ethereum is a drop-in replacement of FAANG.

Is it possible to build Ethereum authentication based on OAuth protocol, given that blockchain lacks the 3 assumptions behind OAuth (3rd party, authorisation use-case, confidentiality between user and the 3rd party)? If it can be done, one can potentially reap the reward of shortening the learning curve of web2.0 developers. Internet history is full of examples where new technologies retrofitting old requirements have an 'evolutionary' advantage. The eas to adoption is not to be ignored.

@jot2re and I worked a few days on a protocol proposal retrofitting OAuth, as you can see in the diagram below.

On top of retrofitting the old Oauth framework, we also have a few important new features in the design. The full draft is authenticator/Dauth.md at main · TokenScript/authenticator · GitHub - Oh, it's also blockchain agonistic by the way.

[weiwu.zhang]

@jot2re was talking with me another day on the entropy needed to derive the delegated site login key, since that determines if the site owner can find out the user's Ethereum address (therefore balance) by looking at the public key of the delegated key, without the user supplying it. Today @fyang1024 mentioned we might consider using the BIP32 master key. Since a master key is typically not used for an Ethereum address (its derivated keys are), deriving from it prevents the site owner from learning user's Ethereum addresses without consent. However, on a second thought, that means it is difficult to prove (without introducing zk, since the master public key is confidential to prevent linkability) that the user owns an Ethereum address from its use of the delegated site login key even if the user wanted to. I added a brief foot note there for this in a commit.

[fyang1024]

@weiwu.zhang I may not have made it clear. I was not suggesting any new idea. I was talking about this sentence in the draft

Assume the user's real Ethereum key is denoted by as sk

What does "real Ethereum key" mean here? It sounds like the other keys mentioned in the draft are not real. Does it mean the Ethereum key controlling the fund instead of the keys used to log in? It's not well-known terminology, or is it?

[weiwu.zhang]

It just refers to Etheruem key behind an Ethereum address. The word "real" is redundant. removed. Thanks.

[sharonsylu]

Feedback from Makoto Inoue (the main dev at ENS Domains behind this RFP oAuth specification) with his reasoning to your question:

1. "The support of oAuth is more about making existing web2 companies to add login with Ethereum easily, rather than completely replacing it." Last comment was in response to your statement Ethereum is a drop-in replacement for FAANG. So your guess about their reasoning - adoption -- has been validated.

2. He briefly looked at Token Negotiation, and from his perspective "it looks like a variant of Token Gated Access which is more of the authorization issue. Authentication via Login and authorisation via tokens are not mutually exclusive imho."

These two points will help guide any submission response to the RFP.

[sharonsylu]

I should be clear, re point 2:

2. His initial reaction to Token Negotiation was in response to this concept proposed 18 months ago: Why Universal Login isn’t working — this might | by Weiwu Zhang | AlphaWallet and AlchemyNFT | Medium

His reaction was not in response to our latest iteration and improvements for Token Negotiator in the DevCon use case.

[victor.zhang]

Tore:

jot2re — Today at 20:12

For me the issue is more the whole concept that OAuth requires an Authorisation server, which in the Ethereum flow, will actually be the same conceptual entity as the user themself. The other issue. The other is that OAuth is actually an authorisation protocol and not directly an authentication protocol. The authentication aspects must be handled in the concrete usage, as is for example done in OpenID connect.

Weiwu wrote:

I had a discussion with @Nick-t yesterday on the same topic and thought that - using oath as-is without centralised confidential party is impossible, because oath is designed for using such a party. - the reason they want oauth is for developer adoption So we went for the idea of using Oauth's flow, format and terminology, but doing it in decentralised way. that should ease the developer adoption (the problem they initially wanted to address) and still 'based on Oauth'. Note that in this version we did not provide a solution that can use Oath the way the standard was written, and did not introduce a centralised confidential party, bot we Oauthed our way as much as possible. @Victor @RubberDucky @Nick-t feedback all very much needed because @Victor signals us to release today. Also I removed the cryptographic protocol because the old protocol wasn't designed with Oauth𝑖𝑛𝑒𝑠𝑠 in mind (with the refresh-key and access-key separation). Instead, I wrote that 'please trust we know our cryptography' and kept on a higher level.

jot2re — Today at 20:26

Ah, sorry, I didn't read all the thread to the end before starting to reply. I agree with Weiwu and Nick. But I do believe that including the cryptography (at least as an appendix) is a good idea. Especially also for the reviewers to be able to consider the efficiency of the approach so they see that we are not doing really expensive zk-snarks or anything like that.

jot2re — Today at 20:38

@weiwu @Nick-t I am not sure how exactly revocation would work. It currently seems to work under the assumption that the user has linked their session key with there Ethereum address. Which might be a fair assumption, but I think we should make make it explicit

Nick-t — Today at 21:22

To provide an idea around revocation - the wallet in the new design is used in place for the central auth server, what would you think if the user was in control of revocation of refresh tokens? For example, the user would have a disconnect option in their wallet UI which would revoke the wallet from re-issuing a new access token upon request. The wallet would know which websites it had issues access tokens to.

jot2re — Today at 21:24

@weiwu @Nick-t I have some more comments to the new description: Under Login it is described that the refresh key pair is derived from the server's challenge. This means that the server can brute-force the user's Ethereum address. Furthermore, if it succeeds, or if the user shares their address later one, it also mean that the server can derive the user's private refresh key and hence completely pretend to be the user towards itself. This might not be an issue but it means it can construct fake logs of user authentication. I suggest we keep the approach discussed of using BIP32 and derive the user's refresh keys based on the user's private Ethereum key, the server's domain and the server's challenge. At least in this case the server cannot create fake authentication requests on behalf of the user once it learns the user's Ethereum address. Although it will still be able to brute force the user's Ethereum address offline.

jot2re — Today at 21:34

So in this situation you assume the wallet can be synced across multiple devices, right? But I can still not see how things are then linked implicitly to the user's Ethereum key. Because as I understand it, the refresh key will be based on the website's domain, the user's Eth address and the website's initial challenge. So in this situation the user would only be able to revoke the session keys if it actually knows the challenge. So this would need to be synced to the user's wallet across devices. In this situation I also fail to see how a user's account is linked across multiple devices unless the user has shared their Eth address or ENS

@weiwu @RubberDucky feedbacks from ENS

jot2re — Today at 21:36

Okay, it sounds like they do really want the full OAuth approach. In that case we should have some sort of solution like EAuth, where a webserver is basically run locally in order to have this be the target of the HTTP redirect that is part of the OAUth flow

[victor.zhang]

fyang1024 — Today at 21:54

Yes, I hope a fully decentralised solution as well. Authentication and Authorisation are complicated. Authentication always involves 2 parties. One party wants to make sure the other party is really the party it serves. Some service does not need too much apart from an ID. It could be a unique username, or ETH address, but other services do need more personal info due to regulation. This reminds me of the attestation idea. If I can selectively expose an Authority attested personal information to the party, that'll serve the purpose.

[jot2re]

Let. me just try to consolidate my points:

1. As @fyang1024 suggests I think we should definitely use BIP32 to derive an anonymous key from the user's Ethereum key for a website. Doing this we do not need to require more entropy. Specifically what I mean is that BIP32 should be used to derive the value R in the specifiction section. This value R is then used in deriving the actual anonymous key pair used for the website based on the user's Ehtereum address, the domain of the website and an unpredictable number. This unpredictable number must be unknown to the website lest it be allowed to brute force the user's Ethereum address. However, as a hack this can be derived either as another BIP32 derived key (simply viewing the key as randomness).

2. By doing this it will allow the user to construct the same anonymous key for the same site on another device. That is, the anonymous key will be derived deterministically from the user's Ethereum key, but in a way where the website does not learn anything about the user's Ethereum address unless the user choses to prove how this is linked to the anonymous key.

3. This also means that a user can revoke an anonymous key, since it derive it on another device. Thus, it can sign a revocation request to the website using the anonymous key it wishes to get revoked and the new key it wishes to use. The new key is then also derived deterministically using BIP32, but simply by increasing the index used in the BIP32 derivation.

[jot2re]

One final comment to the screenshot @victor.zhang shared is that it seems we cannot purely rely on a wallet, but we also need to implement a local HTTP client for the user to run, simply in order to be fully compatible with the OAuth spec. It seems like a bit of a weird requirement, but I can understand the issue of compatibility with previous solutions. However, this will then simply just act as a dummy connecting to the wallet

[victor.zhang]

Tore: Sure, the problem is just that what they want is contradictory. They want a solution that does not rely on any servers (besides the website the user authenticates towards). However OAuth considers an Authorization server to be part of the standard. But it seems that what they actually want is just something like EAuth where the Authorization server is run locally for each user (to ensure the message flow of OAuth can plugged into this solution), even though it formally will not be OAuth since the user itself will be the Authorization server

[victor.zhang]

Oleg: <@!612535920742236161> , Let me share my thoughts about anonymous sessions, maybe something can be helpful:

When we use anonymous sessions from same Wallet Address server doesnt have any relation between multiple session, so:

• If user restarts device then new anonymous session will be created and user has to fill e-commerce billing/shipping data again.
• different browsers/devices will have separate sessions (user can't use single wishlist etc.)
• user cant request session revoke, because server can't confirm that its real owner.

But when we use some deterministic way to create anonymous sessions then every device will use same session and no way to revoke, because everyone use same session and user will revoke own session.

If someone stole device with live session then he/she can revoke real user sessions. So for revoke session better use Wallet signature to ensure that real user asks for revoke.

Would be good to save [device_type, browser_user_agent] to the server session, it will be helpfull to find out what session user wants to revoke.

Would be good to have multiple refresh_key_pair and a way for server to understand that all that refresh_key_pair maybe(because anyone can use ANY address to generate new refresh_key_pair) related to the single session.

To ensite that its same user connected from another device, website can show to the primary session user (who use refresh_key_pair1) some random number and request secondary user to type that value to connect both devices to the single session.

[weiwu.zhang]

@fyang1024 wrote:

This reminds me of the attestation idea. If I can selectively expose an Authority attested personal information to the party, that'll serve the purpose.

Yes, we even wrote a paper for that 3 year ago: Release Ethereum Attestation - paper · SmartTokenLabs/attestation · GitHub

I agree with the direction but I am afraid the style EF works (and EIPs in general) is to support a succinct, simple idea that make sense, not to produce a concrete framework.

In other words, if EF were IETF, they would have welcomed the creation of RESTful API format - a simple change that make sense and made things a lot better; instead of the creation of graphQL - a framework that albeit adaptable, requiring new tools, APIs and skills.

Whatever EF would focus on is something that can be written in 3 pages and worked out in a few weeks, and make sense to smart developers but not necessarily domain experts. In the past, authentication/authorisation solution less than 100 pages is unthinkable (how to describe resources will take 20 pages easily) but today's blockchain space innovation is not driven by domain experts, but by quick iteration of technologies that spans 3 pages long whose immediate application sometimes cost millions lost in Ether hacks, quickly patched up and eventually turned into a solution.

I worked on attestation for many years so of course, I'm very driven to provide attestation based solutions, but that can easily extend the project beyond the scope of EF proposal-requests. Also, you know that I'm confident that token-based authentication and authorisation fits web3 use-cases better than account-based solutions, so "login with Eth Address" as a concept is not going to address future web3 use-cases not yet emerged (why should a website know your Ethereum address if you just want to use a discount privilege token that you bought with Eth to buy a PC game). But, let evolution work out the magic in its own pace. Attestation-based authentication, just like token negotiation, is perhaps too futuristic as an answer to this call for proposal.

[weiwu.zhang]

Refresh key is a key that expires in 2 weeks and generates access keys for websites; refresh key doesn't have to be revealed to the website.

1. The refresh key must be generated using an Ethereum Asset Key. If the user provides a proof, the website can assert the Ethereum Asset Key (public key or address); without proof, the website cannot do so.

2. The refresh key must be able to generate access keys (OAuth's design).

3. Normally, a refresh key generation requires the Ethereum key (a tap on the fingerprint scanner on mobile phones). [Desirable] The refresh key cannot be generated by the Ethereum Asset key and the knowledge of the domain name alone. This way the user can't pre-generate all the refresh keys for future use. i.e. if after 2 weeks the key expires, the user will need to tap on the mobile phone again to unlock Ethereum asset key in order to renew it.

4. [Desirable] there is a version of the protocol that doesn't require the wallet be able to do BIP32 derivation, since some wallet exposed API to do so to apps (Trezor) and some can only do so internally (MetaMask). This means the only use of Ethereum key is to signs stuff and get a signature. This might be used as a 'fall-back' method to allow wallets to slowly (in 1~2 years) ramp up the support.

Linkability

If a user have 2 devices both with Ethereum wallet storing the same Ethereum asset key,

Refresh key's revocation

Revocation is done by one device with access to Ethereum key (a backup phone), to revoke another device with Refresh key but not access to Ethereum key (a stolen mobile phone where the thief can't reproduce the fingerprint to unlock the Etheruem key).

Some thoughts on revocation:

0. The revocation doesn't require knowledge of the refresh key, only the Ethereum asset key and access to the website.

1. [Desirable] If a user didn't expose his main Ethereum asset key, he doesn't need to do so in order to revoke existing sessions (by revoking their refresh keys);

2. There is no need for the capacity of individually revoking a session. A blanket revocation (revoke all prior refresh keys) is acceptable.