Skip to main content
POST
Intercambiar una clave de acceso por un token al portador
Requiere sin acción de IAM. El acceso se decide por las propias reglas del punto final en lugar de por una política. Consulte la descripción anterior.

Cuerpo

Una solicitud de token OAuth 2.0. La codificación de formularios es lo que especifica RFC 6749 y lo que envían las bibliotecas cliente; también se acepta JSON.

Las credenciales del cliente pueden ser enviadas como HTTP Basic (Authorization: Basic base64(key_id:secret), que es lo que la mayoría de las bibliotecas hacen por defecto) o como client_id y client_secret campos. Básico gana si ambos están presentes.

grant_type
enum<string>
requerido

client_credentials es el que se usa para una cuenta de servicio: intercambia un par de claves de acceso por un token, y no necesita nada más.

authorization_code y refresh_token pertenecen al login interactivo que ejecuta una persona (basaltic login), donde el token nombra a un USER en lugar de una cuenta de servicio. Son impulsados por la CLI, no escritos a mano. Compruebe el documento de metadatos del servidor de autorización antes de ramificarse en ellos; solo se anuncian cuando se configura un punto final de autorización.

Opciones disponibles:
client_credentials,
authorization_code,
refresh_token
Ejemplo:

"client_credentials"

client_id
string

El id de la clave de acceso. Omita cuando use HTTP Basic.

Ejemplo:

"BYCLD1a2b3c4d5e6f7"

client_secret
string<password>

La clave de acceso secreta. Omita cuando use HTTP Basic.

duration_seconds
integer

Vida útil del token solicitado. Una extensión de Basaltic, no un parámetro de OAuth — omítelo y obtendrás el valor predeterminado. Los valores fuera del rango se fijan en él en lugar de rechazarse, por lo que pedir un día produce el token más largo permitido.

Rango requerido: 900 <= x <= 43200
Ejemplo:

3600

code
string

El código de autorización de la redirección de consentimiento. Uso único, y válido por cinco minutos. authorization_code concede solo.

code_verifier
string

El verificador PKCE cuyo SHA-256 fue enviado como code_challenge cuando el flujo comenzó (RFC 7636). Requerido con authorization_code: es lo que prueba que este es el cliente que inició el flujo, ya que una CLI no tiene secreto de cliente.

redirect_uri
string

El mismo redirect_uri para el que se emitió el código — para la CLI, urn:ietf:wg:oauth:2.0:oob. Se vuelve a comprobar aquí, por lo que un código no se puede canjear bajo otro diferente (RFC 6749 4.1.3).

Ejemplo:

"urn:ietf:wg:oauth:2.0:oob"

refresh_token
string

refresh_token concede solo. Renueva una sesión de usuario sin otro viaje a través del navegador. Rotar en cada uso - guardar el nuevo.

Respuesta

Un token portador

Respuesta de token RFC 6749.

access_token
string
requerido

Enviar como Authorization: Bearer <token>. Opaca para los clientes: no la analiza, y no introduce nada en la cadena de token.

Ejemplo:

"eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCIsImtpZCI6Ii4uLiJ9..."

token_type
enum<string>
requerido
Opciones disponibles:
Bearer
Ejemplo:

"Bearer"

expires_in
integer
requerido

Segundos hasta que caduque el token.

Ejemplo:

3600

refresh_token
string

Devuelto solo por las concesiones del usuario (authorization_code y refresh_token). Presente la licencia refresh_token para renovarla sin otro viaje de ida y vuelta del navegador; se ROTA en cada uso, por lo que reemplaza la copia almacenada cada vez.

Una cuenta de servicio no obtiene ninguna. Ya tiene una clave de acceso de larga duración y puede simplemente ejecutar client_credentials de nuevo, por lo que un token de actualización sería una segunda credencial para almacenar sin ningún beneficio.