Token web simple (SWT)
Collapse the table of content
Expand the table of content

Token web simple (SWT)

Actualizado: junio de 2015

Este artículo de 2009 se diseñó como una propuesta de estándar de Simple Web Token (SWT) para la Internet Engineering Task Force (IETF). Aunque no está completo y no es un tema de ayuda, proporciona información interesante sobre el formato y el uso de tokens SWT.

Versión 0.9.5.1, 4 de noviembre de 2009

Simple Web Token (SWT) proporciona un formato para la transmisión de una aserción entre dos partes. La aserción es un conjunto de pares nombre/valor que se han codificado como un formulario de HTML y, a continuación, la cadena resultante se confirma mediante un HMAC SHA 256 que usa una clave compartida entre las partes.

  • Dick Hardt (dick.hardt@microsoft.com), editor

  • Yaron Goland (yarong@microsoft.com)

Esta especificación está disponible bajo la versión 0.9 del Open Web Foundation Agreement, que se puede encontrar en [http://groups.google.com/group/open-web-board/web/owf-agreement-for-final-specs---pt-9-draft] [Nota: URL actualizada pendiente.]Puede revisar las copias firmadas de la versión 0.9 del Open Web Foundation Agreement de esta especificación en [Insertar URI de almacenamiento de acuerdos de grupos], que también puede incluir otras partes adicionales a las que se enumeran más arriba. El uso de esta especificación puede estar sujeto a otros derechos de terceros. ESTA ESPECIFICACIÓN SE PROPORCIONA "TAL CUAL". Los colaboradores excluyen expresamente cualquier garantía (expresa, implícita o de otra forma), incluidas las garantías implícitas de comerciabilidad, ausencia de infracción, idoneidad para un propósito específico o titularidad, relativas a la especificación. El implementador de la especificación y el usuario asumen todos los riesgos en cuanto a implementación o de lo contrario con la especificación. EN NINGÚN CASO NINGUNA DE LAS PARTES SERÁ RESPONSABLE DE LA PÉRDIDA DE BENEFICIOS DE NINGUNA OTRA PARTE O DE CUALQUIER FORMA DE DAÑOS INDIRECTOS, ESPECIALES, INCIDENTALES O CONSECUENCIALES DE CUALQUIER CARÁCTER, CAUSA DE ACCIÓN Y TIPO CON RESPECTO A ESTA ESPECIFICACIÓN O SU CONTRATO VIGENTE, YA SE BASEN EN EL INCUMPLIMIENTO DEL CONTRATO, LA RESPONSABILIDAD EXTRACONTRACTUAL (INCLUIDA LA NEGLIGENCIA) U OTRA FORMA, Y SI NO SE HUBIERA AVISADO A LA OTRA PARTE DE LA POSIBILIDAD DE DICHOS DAÑOS.

Simple Web Token (SWT) define un formato para la transmisión de una aserción simple, compacto y con un formato que permite incluirlo fácilmente en un encabezado para protocolos como HTTP. Una aserción simple puede representarse como un conjunto de pares nombre/valor. Los valores codificados como formularios de HTML cumplen los objetivos deseados de fácil comprensión y de formato seguro para los encabezados HTTP.

Dado que los SWT transmitirán información importante sobre identidades y accesos, es necesario encontrar una manera de evitar la manipulación. Por lo tanto, le presentamos el único par nombre/valor obligatorio en SWT: HMACSHA256. Es siempre el último par nombre/valor en un SWT y el valor es el HMAC SHA 256 de los otros pares nombre/valor del SWT.

La elección de otros pares nombre/valor que se utilizan en el SWT está fuera del ámbito de esta especificación. Dicho esto, hay una serie de condiciones y atributos que han demostrado su utilidad en una variedad de marcos de aserción, en concreto: Issuer, Audience y ExpiresOn. Aunque el uso de estos pares nombre/valor no es obligatorio, los definimos aquí para facilitar la interoperabilidad.

Por último, cabe esperar que muchos atributos los crearán las partes que intercambian SWT. Usamos los nombres de DNS inversos para facilitar la creación de nuevos nombres de atributos sin preocuparse por las colisiones de nombres. También se admite el uso de los URI como nombres. Los nombres que no son ni nombres de DNS inversos ni URI son nombres privados, definidos por un acuerdo entre el productor y el consumidor del SWT y, por tanto, están sujetos a colisiones. Los nombres definidos en esta especificación están reservados.

Las palabras clave “DEBE”, “NO DEBE", “NECESARIO”, “DEBERÁ”, “NO DEBERÁ”, “SE RECOMIENDA”, “ES POSIBLE”, “PUEDE” y “OPCIONAL” de este documento se deben interpretar según se describe en [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” (“Palabras clave para indicar niveles de exigencia en los RFC”)).. Los ejemplos del nombre de dominio utilizan [RFC2606] (Eastlake, D. and A. Panitz, “Reserved Top Level DNS Names,” (“Nombres DNS de nivel superior reservados”))..

La parte que la genera un SWT es el productor del SWT. La parte que verifica un SWT es el consumidor del SWT. Antes de generar un SWT, el productor y el consumidor han acordado los atributos que se incluirán en el SWT y han intercambiado una clave de 256 bits generada aleatoriamente fuera de banda. Para generar un SWT, el productor realiza los pasos siguientes:

  1. Se recopilan los pares nombre/valor para transportarlos en el SWT y codificarlos como formulario de tipo application/x-www-form-urlencoded según el punto 17.13.4 de la especificación HTML 4.01

  2. Se introduce el SWT codificado como formulario y la clave acordada en el proceso HMAC SHA 256.

  3. Se toma el valor HMAC resultante y se codifica mediante Base64 según la sección 4 del documento RFC 4648.

  4. Según las reglas de codificación de formularios, se agrega el nombre "HMACSHA256" y el valor HMAC codificado en base 64 al final del SWT codificado como formulario.

El consumidor de un SWT realiza los pasos siguientes para comprobar que un SWT ha sido creado por el productor y no ha sido manipulado:

  1. Se toma el SWT enviado y se divide la cadena en una parte anterior a "&HMACSHA256 =" y la parte restante, que es el HMAC codificado como URL. La primera parte es noHMACSWT.

  2. La URL descodifica la parte restante de la cadena SWT. Esta parte es submittedHMAC.

  3. Se genera un HMAC para noHMACSWT con la clave acordada y, a continuación, se codifica mediante Base64 según la codificación Base64 de la sección 4 del documento RFC 4648. La cadena resultante será localHMAC.

  4. Se lleva a cabo una comparación carácter a carácter de submittedHMAC y localHMAC. Si las cadenas son iguales, el HMAC en el SWT es válido.

Un productor de SWT desea emitir un SWT con la siguiente información:

Issuer = issuer.example.com
ExpiresOn = 1/1/2010, Midnight
com.example.group = gold
over18 = true

Con un valor clave HMAC (representado en base 64) de:

N4QeKa3c062VBjnVK6fb+rnwURkcwGXh7EoNK34n0uM=

En este ejemplo Issuer y ExpiresOn son nombres reservados de esta especificación. El atributo com.example.group es alguna definición acordada sobre la sintaxis y la semántica del grupo que ha creado el propietario del dominio example.com. over18 es un atributo definido como privado, acordado entre el productor y el consumidor del SWT.

Antes de que se pueda codificar el SWT, es necesario convertir ExpiresOn en el número de segundos desde la medianoche del 1/1/1970, hora UTC, hasta la hora de caducidad, la medianoche del 1/1/2010. El resultado es 1262304000.

  1. Codificar los pares nombre/valor en un formulario de HTML. El resultado es (se han insertado saltos de línea para mejorar la legibilidad):

    Issuer=issuer.example.com&
    ExpiresOn=1262304000&
    com.example.group=gold&
    over18=true
    
  2. A continuación, se calcula el HMAC del valor anterior mediante la clave.

  3. Se codifica en Base64 el HMAC. El resultado es:

    AT55+2jLQeuigpg0xm/vn7tjpSGXBUfFe0UXb0/9opE=
    
  4. Se codifica como URL el HMAC codificado en base64 resultante y se adjunta al final de la aserción. El SWT resultante es (se han insertado saltos de línea para mejorar la legibilidad):

    Issuer=issuer.example.com&
    ExpiresOn=1262304000&
    com.example.group=gold&
    over18=true&
    HMACSHA256=
    AT55%2B2jLQeuigpg0xm%2Fvn7tjpSGXBUfFe0UXb0%2F9opE%3D
    

  1. Se divide el SWT utilizando: &HMACSHA256= y se obtiene una cadena noHMACSWT de (se han insertado separadores de línea para mejorar la legibilidad):

    Issuer=issuer.example.com&
    ExpiresOn=1262304000&
    com.example.group=gold&
    over18=true&
    
    y la cadena submittedHMAC de:

    AT55%2B2jLQeuigpg0xm%2Fvn7tjpSGXBUfFe0UXb0%2F9opE%3D
    
  2. A continuación, se descodifica desde URL submittedHMAC y el resultado es:

    AT55+2jLQeuigpg0xm/vn7tjpSGXBUfFe0UXb0/9opE=
    
  3. A continuación, se calcula localHMAC mediante noHMACSWT y el valor de clave HMAC, se codifica en base64 el resultado y se obtiene el valor de localHMAC siguiente:

    AT55+2jLQeuigpg0xm/vn7tjpSGXBUfFe0UXb0/9opE=
    
  4. Se comparan submittedHMAC y localHMAC, y se comprueba si son la misma cadena. Después, se descodifica desde URL noHMACSWT para obtener acceso a los valores de SWT.

Los siguientes pares de nombre/valor son opcionales. Se han definido para facilitar la interoperabilidad para muchos de los escenarios comunes donde son útiles.

 

Nombre Sintaxis del valor Semántica del valor

Issuer

Una cadena UTF-8

Identifica la parte que emite el SWT.

ExpiresOn

Una cadena ASCII que representa un número entero de base 10 sin signo.

Identifica el momento a partir del cual el SWT no se debe aceptar para su posterior procesamiento.

La fecha y hora de expiración se registra como el número de segundos que transcurrirán desde 1970-01-01T0:0:0Z hasta el momento de expiración, medido en UTC.

Público

Una cadena UTF-8

Identifica la audiencia del SWT para la que está destinado. El objetivo es que si un consumidor de SWT recibe un SWT con un valor de audiencia que no identifique la audiencia de SWT, el SWT se rechazará.

Un productor de SWT puede utilizar un nombre DNS inverso o un URI para definir atributos adicionales.

Un productor y un consumidor de un SWT pueden convenir cualquier nombre de atributo que no sea un nombre público o reservado. Estos nombres no deben estar en la lista de nombres reservados que figura en la sección anterior "Nombres reservados". A diferencia de los nombres públicos, los nombres privados están sujetos a colisiones y deben utilizarse con precaución.

Vea también

Mostrar:
© 2016 Microsoft