diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index 7db6fe441..c2ecdcf65 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -6,8 +6,8 @@ Title: Stellar Web Authentication Author: Sergey Nebolsin <@nebolsin>, Tom Quisel , Leigh McCulloch <@leighmcculloch>, Jake Urban Status: Active Created: 2018-07-31 -Updated: 2020-08-14 -Version 2.0.0 +Updated: 2020-10-07 +Version 2.1.0 ``` ## Simple Summary @@ -23,7 +23,8 @@ The authentication flow is as follows: 1. The client obtains a unique [`challenge`](#challenge), which is represented as specially formed Stellar transaction 1. The client verifies that the transaction has an invalid sequence number 0. This is extremely important to ensure the transaction isn't malicious. 1. The client verifies that the transaction is signed by the `SIGNING_KEY` specified by the requested service's [SEP-1 stellar.toml](sep-0001.md). -1. The client verifies that the transaction includes a Manage Data operation, and that the value contains the home domain used to request the challenge. +1. The client verifies that the transaction has a single Manage Data operation with its source account set to the user's account and value set to a nonce value. The client ignores the home domain included. +1. The client verifies that if the transaction has other Manage Data operations they all have their source accounts set to the the server's account. 1. The client signs the transaction using the secret key(s) of signers for the user's Stellar account 1. The client submits the signed challenge back to the server using [`token`](#token) endpoint 1. The server checks that the user's account exists @@ -68,7 +69,7 @@ In order for browsers-based wallets to validate the CORS headers, as [specified ### Challenge -This endpoint must respond with a Stellar transaction signed by the server that has an invalid sequence number (0) and thus cannot be executed on the Stellar network. The client can then sign the transaction using standard Stellar libraries and submit it to [`token`](#token) endpoint to prove that they control their account. This approach is compatible with hardware wallets such as Ledger. The client must also verify the server's signature to be sure the challenge is signed by the `SIGNING_KEY` from the server's [`stellar.toml`](sep-0001.md). Additionally, the client must ensure that the challenge transaction was created by the requested service by checking the value of the Manage Data operation. +This endpoint must respond with a Stellar transaction signed by the server that has an invalid sequence number (0) and thus cannot be executed on the Stellar network. The client can then sign the transaction using standard Stellar libraries and submit it to [`token`](#token) endpoint to prove that they control their account. This approach is compatible with hardware wallets such as Ledger. The client must also verify the server's signature to be sure the challenge is signed by the `SIGNING_KEY` from the server's [`stellar.toml`](sep-0001.md). #### Request @@ -97,9 +98,11 @@ On success the endpoint must return `200 OK` HTTP status code and a JSON object * source account set to server's signing account * invalid sequence number (set to 0) so the transaction cannot be run on the Stellar network * time bounds: `{min: now(), max: now() + 900 }` (we recommend expiration of 15 minutes to give user time to sign transaction) - * operations: `manage_data(source: client_account, key: ' auth', value: random_nonce())` - * The value of key is the fully qualified domain name of the web service requiring authentication followed by `auth`. It can be at most 64 characters. - * The value must be 64 bytes long. It contains a 48 byte cryptographic-quality random string encoded using base64 (for a total of 64 bytes after encoding). + * operations: + * `manage_data(source: client_account, key: ' auth', value: random_nonce())` + * The value of key is the fully qualified domain name of the web service requiring authentication followed by `auth`. It can be at most 64 characters. + * The value must be 64 bytes long. It contains a 48 byte cryptographic-quality random string encoded using base64 (for a total of 64 bytes after encoding). + * zero or more `manage_data(source: server_account, ...)` reserved for future use * signature by the service's stellar.toml `SIGNING_KEY` * `network_passphrase`: (optional but recommended) Stellar network passphrase used by the server. This allows the client to verify that it's using the correct passphrase when signing and is useful for identifying when a client or server have been configured incorrectly. @@ -136,8 +139,7 @@ To validate the challenge transaction the following steps are performed by the s * verify that transaction source account is equal to the server's signing key; * verify that transaction has time bounds set, and that current time is between the minimum and maximum bounds; * verify that transaction contains a single [Manage Data](https://www.stellar.org/developers/guides/concepts/list-of-operations.html#manage-data) operation that: - * has a non-null source account - * has the service's home domain as the key of the operation + * has a non-null source account * verify that transaction envelope has a correct signature by server's signing key; * if the operation's source account exists: * verify that client signatures count is one or more; @@ -147,6 +149,7 @@ To validate the challenge transaction the following steps are performed by the s * if the operation's source account does not exist: * verify that client signature count is one; * verify that client signature is correct for the master key of the account address; +* verify that transaction containing additional Manage Data operations have their source account as the server signing key; * verify that transaction sequenceNumber is equal to zero; * use operations's source account to determine the authenticating client and perform any additional service-specific validations.