Saltar al contenido principal
Versión: 2,11

Autenticación Stellar

Habilitar la Autenticación Stellar

Las aplicaciones de billeteras basadas en Stellar crean sesiones autenticadas con anchors Stellar al demostrar que ellos, o sus usuarios, tienen suficiente control sobre una cuenta Stellar. Una vez autenticada, la aplicación de billetera utiliza un token de sesión proporcionado por el anchor en solicitudes posteriores a los servicios estandarizados del anchor.

La Anchor Platform admite esta forma de autenticación con una configuración mínima por parte del negocio.

# dev.env
SEP10_ENABLED=true
SEP10_HOME_DOMAIN=localhost:8080
SECRET_SEP10_SIGNING_SEED="a Stellar private key"
SECRET_SEP10_JWT_SECRET="a secret encryption key"

SEP_10_HOME_DOMAIN es la propiedad home_domain utilizada por [sep-10]. El valor de configuración debe ser igual al host del archivo toml. Si estás alojando el archivo toml a través de la Platform, (SEP1_ENABLED está establecido en true), el archivo toml se alojará en el servidor SEP.

SECRET_SEP10_SIGNING_SEED es la clave privada de la clave pública que has especificado como SIGNING_KEY en tu archivo stellar.toml. Se utilizará para firmar los desafíos de autenticación presentados a las aplicaciones de billetera, siempre que estés en posesión de la SIGNING_KEY. Las billeteras comprobarán esta firma antes de firmar y enviar de vuelta el desafío de autenticación.

SECRET_SEP10_JWT_SECRET es la clave de cifrado que se utilizará para firmar y verificar los tokens de autenticación que emitas a las aplicaciones de billetera después de que ellas o sus usuarios hayan demostrado control sobre su cuenta Stellar.

información

Por defecto, la Anchor Platform permite que cualquier persona con una cuenta Stellar se autentique con tus servicios. Si deseas permitir solo a los usuarios de una aplicación de billetera particular que se autentiquen, o quieres prohibir a usuarios específicos que se autentiquen, utiliza las siguientes variables de entorno. Esta es una función opcional y solo debe ser añadida si es un requisito del negocio.

Configurar con Atribución de Cliente

SEP10_CLIENT_ATTRIBUTION_REQUIRED informa a la Anchor Platform si debe permitir que los usuarios de billeteras no custodiales se autentiquen sin que la billetera también se identifique.

CLIENTS es la lista de servidores de billetera externos o clientes con los que el servidor Anchor puede comunicarse de manera segura.

# dev.env
SEP10_CLIENT_ATTRIBUTION_REQUIRED=true
clients:
# Each item in the list may contain the following fields:
# - name: (required) the name of the client
# - type: (required) `custodial` or `noncustodial`
#
# If the type is `custodial`,
# - signing_keys: (required) the custodial SEP-10 signing key of the client.
# - callback_url: (optional) the URL of the client's callback API endpoint.
# If one of SEP-specific URLs is also provided, then this URL will be used as a fallback.
# For example, if `callback_url_sep6` is not provided, but `callback_url_sep24` is,
# SEP-6 transactions will use the `callback_url` as the callback URL. This field is
# deprecated and will be removed in 3.0.
# - callback_url_sep6: (optional) the URL of the client's SEP-6 callback API endpoint.
# - callback_url_sep24: (optional) the URL of the client's SEP-24 callback API endpoint.
# - callback_url_sep31: (optional) the URL of the client's SEP-31 callback API endpoint.
# - callback_url_sep12: (optional) the URL of the client's SEP-10 callback API endpoint.
# - allow_any_destination: (optional) default to false. If set to true, allows any destination for deposits.
# - destination_accounts: (optional) list of accounts allowed to be used for the deposit.
# If allows_any_destinations set to true, this configuration option is ignored.
#
# If the type is `noncustodial`,
# - domains: (required) the domains of the client.
# - callback_url: (optional) the URL of the client's callback API endpoint

# custodial client
- name: custodial-client1
type: custodial
signing_keys: "the signing key 1 of the client1","the signing key 2 of the client1"
callback_url: https://callback.custodial-client1.com/api/v1/anchor/callback
callback_url_sep6: https://callback.custodial-client1.com/api/v1/anchor/callback/sep6
callback_url_sep12: https://callback.custodial-client1.com/api/v1/anchor/callback/sep12
allow_any_destination: false
destination_accounts: destAccount1,destAccount2
- name: custodial-client2
type: custodial
signing_keys: "the signing key of the client2",

# noncustodial client
- name: noncustodial-client1
type: noncustodial
domains: noncustodial-client1.co,noncustodial-client1.com
callback_url: https://callback.noncustodial-client1.co/api/v2/anchor/callback
callback_url_sep6: https://callback.noncustodial-client1.co/api/v2/anchor/callback/sep6
callback_url_sep12: https://callback.noncustodial-client1.co/api/v2/anchor/callback/sep12
- name: noncustodial-client2
type: noncustodial
domains: noncustodial-client2.com

SEP10_CLIENT_ATTRIBUTION_REQUIRED informa a la Anchor Platform si debe permitir que los usuarios de billeteras no custodiales se autentiquen sin que la billetera también se identifique.

CLIENTS es la lista de servidores de billetera externos o clientes con los que el servidor Anchor puede comunicarse de manera segura.

Modificar un Archivo de Información Stellar

A continuación, vamos a modificar el archivo stellar.toml creado anteriormente. Las billeteras necesitan saber que la funcionalidad SEP-10 es admitida por tu negocio.

# dev.stellar.toml
ACCOUNTS = ["add your public keys for your distribution accounts here"]
SIGNING_KEY = "add your signing key here"
NETWORK_PASSPHRASE = "Test SDF Network ; September 2015"

WEB_AUTH_ENDPOINT = "http://localhost:8080/auth"

[DOCUMENTATION]
ORG_NAME = "Your organization"
ORG_URL = "Your website"
ORG_DESCRIPTION = "A description of your organization"