|
| 1 | +--- |
| 2 | +title: Using Ethereum for web2 authentication |
| 3 | +description: After reading this tutorial, a developer will be able to integrate Ethereum login (web3) with SAML login, a standard used in web2 to provide single sign-on and other related services. This allows access to web2 resources to be authenticated through Ethereum signatures, with the user attributes coming from attestations. |
| 4 | +author: Ori Pomerantz |
| 5 | +tags: ["web2", "authentication"] |
| 6 | +skill: beginner |
| 7 | +lang: en |
| 8 | +published: 2025-04-15 |
| 9 | +--- |
| 10 | + |
| 11 | +## Introduction |
| 12 | + |
| 13 | +[SAML](https://www.onelogin.com/learn/saml) is a standard used on web2 to allow an [identity provider (IdP)](https://en.wikipedia.org/wiki/Identity_provider#SAML_identity_provider) to provide user information for [service providers (SP)](https://en.wikipedia.org/wiki/Service_provider_(SAML)). |
| 14 | + |
| 15 | +In this tutorial you learn how to integrate Ethereum signatures with SAML to allow users to use their Ethereum wallets to authenticate themselves to web2 services that don't support Ethereum natively yet. |
| 16 | + |
| 17 | +### SAML for Ethereum people |
| 18 | + |
| 19 | +SAML is a centralized protocol. A service provider (SP) only accepts assertions (such as "this is my user John, he should have permissions to do A, B, and C") from an identity provider (IdP) if it has a pre-existing trust relationship with it. |
| 20 | + |
| 21 | +For example, the SP can be a travel agency providing travel services to companies, and the IdP can be a company's internal web site. When employees need to book business travel, the travel agency sends them for authentication by the company before letting them actually book travel. |
| 22 | + |
| 23 | +```mermaid |
| 24 | +
|
| 25 | +sequenceDiagram |
| 26 | + participant Browser |
| 27 | + participant IdP |
| 28 | + participant SP |
| 29 | +
|
| 30 | + opt The browser can also go directly to the IdP |
| 31 | + Browser->>SP: I want to do X |
| 32 | + note over SP: Who is this? |
| 33 | + SP->>Browser: What is your organization |
| 34 | + Browser->>SP: Y org |
| 35 | + SP->>Browser: Redirect to Y's IdP |
| 36 | + end |
| 37 | + Browser->>IdP: Can you log me in to SP? |
| 38 | + note over Browser, IdP: Authentication (by any mechanism) |
| 39 | + IdP->>Browser: Redirect to the SP, with this (signed) user profile |
| 40 | + Browser->>SP: Here are my credentials, from the IdP |
| 41 | + SP->>Browser: Welcome, you have permissions to do X |
| 42 | +``` |
| 43 | + |
| 44 | +This is the way the three entities, the browser, SP, and IdP, negotiate for access. The SP does not need to know anything about the user using the browser in advance, just to trust the IdP. |
| 45 | + |
| 46 | +### Ethereum for SAML people |
| 47 | + |
| 48 | +Ethereum is a decentralized system. |
| 49 | + |
| 50 | +```mermaid |
| 51 | +
|
| 52 | +sequenceDiagram |
| 53 | + participant Browser |
| 54 | + participant Server |
| 55 | +
|
| 56 | + Browser->>Server: Can I have access to this app? |
| 57 | + Server->>Browser: Can you sign this message: "I am signing for service X, nonce Y"? |
| 58 | + note over Browser: Sign with the private key |
| 59 | + Browser->>Server: Sure, the signature is 0x00...00BAD060A7 |
| 60 | + note over Server: Check signature, get address |
| 61 | + Server->>Browser: Hello, 0x00000000000000000000000000000000DeaDBeef. |
| 62 | +``` |
| 63 | + |
| 64 | +Users have a a private key (typically held in a browser extension). From the private key you can derive a public key, and from that a 20-byte address. When users need to log into a system, they are requested to sign a message with a nonce (a single-use value). The server can verify the signature was created by that address. |
| 65 | + |
| 66 | +```mermaid |
| 67 | +
|
| 68 | +sequenceDiagram |
| 69 | + participant Browser |
| 70 | + participant Server |
| 71 | + participant Node as Ethereum Node |
| 72 | +
|
| 73 | + Server->>Node: I want to know the name for 0x00...00DeaDBeef, <br/> What did <trusted address> say about it? |
| 74 | + Node->>Server: The name for this address is John Doe |
| 75 | + Server->>Browser: Hello John Doe |
| 76 | +``` |
| 77 | + |
| 78 | +The signature only provides the address. To get other user attributes, you typically use [attestations](https://attest.org/). An attestation typically has these fields: |
| 79 | + |
| 80 | +- **Attestor**, the address that made the attestation |
| 81 | +- **Recipient**, the address to which the attestation applies |
| 82 | +- **Data**, the data being attested, such as name, permissions, etc. |
| 83 | +- **Schema**, the ID of the schema used to interpret the data. |
| 84 | + |
| 85 | +Because of the decentralized nature of Ethereum, any user can make attestations. The attestor's identity is important to identify which attestations we want to consider reliable. |
| 86 | + |
| 87 | +## Setup |
| 88 | + |
| 89 | + |
| 90 | +1. Introduction: Why do this? |
| 91 | + 1. SAML for Ethereum people |
| 92 | + 1. Ethereum for SAML people |
| 93 | +1. Setup |
| 94 | + 1. Creating a SAML service provider (SP) |
| 95 | + 1. Creating a (for now) traditional SAML identity provider (IdP) |
| 96 | +1. Signing in |
| 97 | + 1. Getting a signature through a wallet |
| 98 | + 1. Using that signature for SAML |
| 99 | +1. User attributes |
| 100 | + 1. Why? The service provider might not know the user |
| 101 | + 1. Getting user attributes from EAS |
| 102 | + 1. Passing those user attributes to the SP. |
| 103 | +1. Conclusion |
| 104 | + 1. When is this a good solution? |
| 105 | + 2. Using [MPC](https://ethresear.ch/c/cryptography/mpc/14) to remove the IdP's ability to cheat (just the idea, but I might implement it in a sequel article |
0 commit comments