Technical Details
WebsiteDiscordOverviewSupport
  • Overview
  • Identity Protocol
    • Overview
    • Registry
    • Nodes & NFTs
      • Manufacturer
      • Vehicle ID
      • DeviceID
      • License
    • Auxiliary Contracts
      • Access Control
      • AdLicenseValidator
      • Eip712Checker
      • Mapper
    • Architecture
    • Pairing
  • Device Canonical Name
    • Overview
    • Contracts
      • DcnRegistry
      • DcnManager
      • PriceManager
      • Resolvers
  • Token & Governance
    • Token
    • Rewards
    • Governance
  • Data
    • Platform Components
    • DBC Decoding
    • Software-Only Connectivity
    • Data Storage
    • Validation
    • Data Dictionary
      • Sample Data
  • Hardware
    • Ecosystem
    • Open Hardware Spec
    • Manufacturing License
      • DIMO Memorandum of Understanding
      • Staking $DIMO for a Manufacturer License
    • Device License
      • Device Minting Certificate
      • Hardware and Security Audit
      • Testing and Quality Control
  • Abstraction
    • Sign In With Ethereum
    • Metatransactions
  • Security
    • Methods
    • Audits
    • User Privacy
Powered by GitBook
On this page
  1. Abstraction

Sign In With Ethereum

PreviousTesting and Quality ControlNextMetatransactions

Last updated 1 year ago

In addition to traditional login methods such as Google and Apple, DIMO allows users to sign in with their Ethereum wallets.

To verify that a user possesses the private key for a particular Ethereum address, the DIMO identity server sends the user a challenge message of the following form:

{
  // Usual fields like sub, iss, aud.
  "ethereum_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F",
  "provider_id": "web3"
}

One way in which Ethereum logins differ from other kinds is in the absence of refresh tokens: these are disabled for wallet log-ins since there is no way to revoke access to a basic Ethereum account, as one might do for a Google account by changing the password. A user simply must log in again to continue using the app once the token has expired.

The random string, or , guards against replay attacks and expires after a short duration. "Signing" here means passing the message to , which adds a short prefix and calculates the according to Appendix F of . The user completes this operation in their chosen wallet software and submits the signature to the identity server.

On the backend, the signature is combined with the hash of the original message to and hence an address. If this address is the expected one then the server trusts that the submitter controls the corresponding Ethereum wallet.

Following this, the server issues a signed , a , to the user carrying some non-traditional fields:

Various microservices accept this as a credential, verifying its authenticity using the advertised public key of the identity server. This part is not specific to Ethereum logins, and most of this functionality is inherited from , an open-source identity provider common in the Kubernetes world. The is similarly open-source and available for others to use. Relying on public key crytography allows most DIMO services to avoid calling out to a central authorization server upon every request.

We should also note the existence of the specification, currently in review as , which attempts to standardize a set of fields for challenge messages such as the one above. We're interested in adopting the final standard, particularly if wallet support grows.

nonce
eth_sign
ECDSA signature
the yellow paper
recover a public key
identity token
JWT
Dex
DIMO Dex fork
Sign-In With Ethereum
EIP-4361
A challenge signature request in Metamask