Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 32 additions & 2 deletions docs/astro.config.mjs
Original file line number Diff line number Diff line change
Expand Up @@ -35,11 +35,14 @@ export default defineConfig({
// defaultLocale: 'root',
locales: {
root: {
// English docs in `src/content/docs`
label: 'English',
lang: 'en'
},
es: {
label: 'Español'
// Spanish docs in `src/content/docs/es`
label: 'Español',
lang: 'es'
}
},
expressiveCode: {
Expand Down Expand Up @@ -84,56 +87,75 @@ export default defineConfig({
sidebar: [
{
label: 'Overview',
translations: { es: 'Descripción general' },
items: [
{ label: 'Getting started', link: '/overview/getting-started/' },
{
label: 'Getting started',
translations: { es: 'Cómo empezar' },
link: '/overview/getting-started/'
},
{
label: 'Concepts',
translations: { es: 'Conceptos' },
collapsed: false,
items: [
{
label: 'Wallet addresses',
translations: { es: 'Direcciones de billetera' },
link: '/concepts/wallet-addresses/'
},
{
label: 'Resources',
translations: { es: 'Recursos' },
link: '/concepts/resources/'
},
{
label: 'Authorization',
translations: { es: 'Autorización' },
link: '/concepts/auth/'
},
{
label: 'Payment methods',
translations: { es: 'Métodos de pago' },
link: '/concepts/payments/'
},
{
label: 'Open Payments flow',
translations: { es: 'Flujo de Open Payments' },
link: '/concepts/op-flow/'
}
]
},
{
label: 'Identity and access management',
translations: { es: 'Gestión de la identidad y el acceso' },
collapsed: true,
items: [
{
label: 'Grant negotiation and authorization',
translations: {
es: 'Negociación y autorización de las concesiones'
},
link: '/identity/grants/'
},
{
label: 'Identity providers',
translations: { es: 'Proveedores de identidad' },
link: '/identity/idp/'
},
{
label: 'Client keys',
translations: { es: 'Claves de cliente' },
link: '/identity/client-keys/'
},
{
label: 'HTTP signatures',
translations: { es: 'Firmas de mensajes HTTP' },
link: '/identity/http-signatures/'
},
{
label: 'Hash verification',
translations: { es: 'Verificación de hash' },
link: '/identity/hash-verification/'
}
]
Expand Down Expand Up @@ -260,28 +282,36 @@ export default defineConfig({
},
{
label: 'Guides',
translations: { es: 'Guías' },
collapsed: true,
items: [
{
label: 'Make a one-time payment',
translations: { es: 'Cómo efectuar un pago único' },
link: '/guides/make-onetime-payment/'
},
{
label: 'Make recurring payments',
translations: { es: 'Realizar pagos recurrentes' },
link: '/guides/make-recurring-payments/'
},
{
label: 'Split an incoming payment',
translations: { es: 'Dividir un pago entrante' },
link: '/guides/split-payments/'
},
{
label: 'Get an outgoing payment grant for future payments',
translations: {
es: 'Obtener una concesión de pago saliente para pagos futuros'
},
link: '/guides/outgoing-grant-future-payments/'
}
]
},
{
label: 'Resources',
translations: { es: 'Recursos' },
collapsed: true,
items: [
{
Expand Down
52 changes: 52 additions & 0 deletions docs/src/content/docs/es/concepts/auth.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
---
title: Autorización
parent: Concepts
---

import { LinkOut, Tooltip } from '@interledger/docs-design-system'

:::tip[Resumen]
La autorización en Open Payments (estándar de pagos abiertos) se refiere al proceso mediante el cual un cliente obtiene el permiso de un propietario de recursos para acceder a los recursos protegidos y operar en ellos.
:::

Open Payments aprovecha el Protocolo de Negociación y Autorización de Concesiones <LinkOut href='https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol'>(Grant Negotiation and Authorization Protocol, GNAP)</LinkOut> como el mecanismo mediante el cual un programa de software, conocido como “instancia de cliente” (o simplemente “cliente”), recibe la delegación de autorización para utilizar las interfaces de programación de aplicaciones (application programming interfaces, API) de Open Payments para interactuar con las cuentas admitidas.

## Servidor de autorización

El servidor de autorización concede permisos para que un cliente acceda a las API de Open Payments y los recursos de `incoming-payment`, `quote` y `outgoing-payment`. Para ello, emite tókenes de acceso que representan un conjunto de derechos de acceso o atributos concedidos al cliente. Con los tókenes de acceso adecuados, el cliente puede ejecutar las operaciones permitidas, como crear pagos entrantes y salientes, en nombre del propietario del recurso (resource owner, RO).

### Relación entre las concesiones y los tókenes de acceso

Una **concesión** es una autorización que emite el RO para permitir que un cliente acceda a recursos específicos. La concesión de autorización especifica el tipo de acciones que el cliente puede efectuar. Puede requerir la interacción del usuario y está sujeta al consentimiento del RO. El servidor de autorización valida la concesión cada vez que el cliente utiliza su token de acceso.

Un **token de acceso** se emite luego de que el servidor de autorización aprueba una solicitud de concesión. Este token funciona como una credencial que el cliente utiliza para su propia autenticación a la hora de emitir solicitudes de acceso a recursos protegidos. El token de acceso contiene información sobre los permisos concedidos, lo que incluye las acciones específicas que el cliente puede realizar y los recursos a los que puede acceder.

## Tipos de concesiones

En esta sección, se detallan los diferentes tipos de concesiones de autorización que los clientes pueden solicitar en el entorno de Open Payments. Aunque el flujo suele comenzar con una concesión para un pago entrante, existen situaciones en las que otros tipos de concesiones pueden solicitarse primero.

### Pago entrante

Por lo general, para iniciar el flujo de Open Payments, el cliente solicita una concesión de autorización para un pago entrante al servidor de autorización que corresponde al _destinatario_. Sin embargo, existen situaciones en las que el cliente solicita una concesión de autorización para un pago saliente primero, como en el caso de Web Monetization (estándar de monetización web).

El cliente puede solicitar una sola concesión de autorización para crear varios pagos entrantes destinados a distintas cuentas compatibles con Open Payments, siempre que todas las cuentas pertenezcan a la misma <Tooltip content="Entidad que administra la cuenta" client: load><span>ASE</span></Tooltip>.

Por defecto, las concesiones de autorización para pagos entrantes no son interactivas; esto significa que no se requiere la interacción de una persona (por lo general, el usuario del cliente) para que el servidor de autorización emita un token de acceso.

### Cotización

Una vez que el cliente recibe una concesión de autorización para un pago entrante y se crea un recurso de pago entrante en la cuenta del destinatario, el cliente solicita la concesión de autorización para una cotización al servidor de autorización que corresponde al _remitente_. El cliente puede solicitar una sola concesión de autorización para crear varias cotizaciones destinadas a distintas cuentas compatibles con Open Payments, siempre que todas las cuentas pertenezcan a la misma <Tooltip content="Entidad que administra la cuenta" client: load><span>ASE</span></Tooltip>.

Por defecto, las concesiones de autorización para cotizaciones no son interactivas; esto significa que no se requiere la interacción de una persona (por lo general, el usuario del cliente) para que el servidor de autorización emita un token de acceso.

### Pago saliente

Una vez que el cliente avanzó en las secciones de pagos entrantes y cotizaciones del flujo de Open Payments, está listo para solicitar una concesión de autorización para un pago saliente al servidor de autorización que corresponde al _remitente_.

En Open Payments, se exige que las solicitudes de concesiones de autorización para los pagos salientes sean interactivas. Esto significa que la interacción explícita de una persona (por lo general, el usuario del cliente) es un paso obligatorio en el proceso de delegación.

Luego de una interacción correcta, el cliente debe emitir una [solicitud de continuación de la concesión de autorización](/apis/auth-server/operations/post-continue), para que el servidor de autorización sepa que debe emitir un token de acceso.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Luego de una interacción correcta, el cliente debe emitir una [solicitud de continuación de la concesión de autorización](/apis/auth-server/operations/post-continue), para que el servidor de autorización sepa que debe emitir un token de acceso.
Luego de una interacción correcta, el cliente debe emitir una [solicitud de continuación de la concesión de autorización](/es/apis/auth-server/operations/post-continue), para que el servidor de autorización sepa que debe emitir un token de acceso.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JoblersTune I don't think the API specs will ever be translated outside of English. Is it still a good idea to point to a lang folder?


## Más información sobre la autorización

Para profundizar en los temas relacionados con la autorización, por ejemplo, el Protocolo de Negociación y Autorización de Concesiones (Grant Negotiation and Authorization Protocol, GNAP) y la solicitud de concesiones de autorización, consulte la sección [Negociación y autorización de concesiones](/es/identity/grants) y otras páginas incluidas en **Gestión de la identidad y el acceso**.
Loading