Contratos de Interfaz
Especificación para el consumo de los endpoints del protocolo de
OAuth 2.0
Mayo de 2019
© 2018 Novell de México S.A de C.V., Propietario y confidencial Servicio de Administración Tributaria (SAT) y
Novell Inc. Todos los derechos reservados.
Ninguna sección de esta publicación puede ser reproducida, transmitida, transcrita o traducida a otro idioma,
almacenada en cualquier forma, medio y termino, sin la autorización escrita del Servicio de Administración
Tributaria (SAT) y Novell de México S.A de C.V.
Entretanto cada precaución ha sido tomada en la elaboración de este documento, Novell de México S.A de C.V.
no asume ninguna responsabilidad de los errores, omisiones o daños resultados por el uso de la información
adjunta.
Productos, nombres corporativos, marcas registradas o marcas registradas por otras compañías, son utilizadas
solamente, sin el intento de infringir, para explicación y beneficio de su dueño.
CONTROL DE DOCUMENTO
Versión Fecha Responsable Cambios realizados Autorización
1.0 31/05/19 Victor Ramírez Creación del documento César Nava Camacho
2.0 13/09/19 Victor Ramírez Se agrega grant de PKCE César Nava Camacho
DOCUMENTOS RELACIONADOS
Versión Documento relacionado Objetivo del documento Responsable
Contenido
OBJETIVO ....................................................................................................................................................................................... 4
AUTHORIZATION CODE GRANT ......................................................................................................................................................... 5
AUTHORIZATION CODE WITH PKCE ................................................................................................................................................... 7
IMPLICIT GRANT.............................................................................................................................................................................. 9
CLIENT CREDENTIALS ..................................................................................................................................................................... 10
RESOURCE OWNER CREDENTIALS ................................................................................................................................................... 11
REFRESH TOKEN ENDPOINT ............................................................................................................................................................ 12
INTROSPECTION TOKEN ENDPOINT ................................................................................................................................................. 13
TOKEN INFO ENDPOINT ................................................................................................................................................................. 14
REVOKE TOKEN ENDPOINT ............................................................................................................................................................. 15
USERINFO ENDPOINT .................................................................................................................................................................... 16
OBJETIVO
El presente documento específica a cualquier aplicación cliente el consumo para los endpoints del protocolo de
OAuth 2.0 expuestos por la plataforma de control de accesos, se detallan los parámetros que son requeridos,
opcionales y recomendados en las peticiones realizadas al NAM. También se detallan los parámetros de
respuesta que envía el NAM a los clientes.
Para poder realizar el consumo de cualquiera de estos endpoints es necesario que la aplicación cliente sea
registrada previamente en la plataforma de control de accesos.
El servidor de autorización cuenta también con un endpoint en donde se desplega su metadata:
[Link]
Así como un endpoint en donde expone los certificados públicos (JWKS) para que se pueda validar la firma
digital de cualquier Access Token:
[Link]
AUTHORIZATION CODE GRANT
El flujo para el Authorization Code Grant consiste en un proceso de 2 pasos:
1. Obtener del Authorization Server un código de autorización con corto tiempo de vida.
2. Intercambiar el código de autorización por un ID Token y un Access Token.
Obtener un código de autorización:
ENDPOINT: [Link]
MÉTODO: GET
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
response_type Requerido El valor por defecto que se especifica es: code.
redirect_uri Requerido Cualquier uri de redirección que fue registrada en el NAM para esa
aplicación cliente.
scope Requerido La lista de los scopes que la aplicación requiere, deberá contener por lo
menos el scope de “openid”, los scopes deberán ser separados por “+” o
“%20”.
resourceServer Opcional El nombre del Resource Server registrado en el NAM, es para utilizar el
método de encriptado por defecto de ese Resource Server para el Access
Token.
prompt Opcional login: si se desea que el usuario se re-autentique
consent: si se desea que el usuario vuelva a dar los permisos a ese cliente.
state Recomendado Un valor único definido por el cliente para mantener el estado entre el
request y el callback.
max_age Opcional Tiempo máximo en segundos de espera para que el usuario se autentique.
acr_values Opcional Uri del contrato de NAM a mostrar.
RESPONSE:
La respuesta se enviará a la uri de redirección enviada como parámetro en la petición anterior.
Parámetro Requerido Descripción
code Requerido El código de autorización de longitud variable, el cliente no deberá asumir
la longitud del código.
state Requerido Contiene el estado enviado en el parámetro de la petición anterior.
EJEMPLO DE PETICIÓN Y RESPUESTA:
HTTP/1.1 GET /nidp/oauth/nam/authz? &response_type=code &client_id=bb775b12-bbd4-423b-83d9-647aeb98608d
&redirect_uri=[Link] &scope=email &nonce=ab8932b6 &state=AB32623HS
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Host: [Link]
RESPONSE
HTTP/1.1 302 Found
Location: [Link] code=/wEBAAY..........Ws1gQ~~ &scope=email Content-Length: 0
Intercambiar el código de autorización por un ID Token y un Access Token:
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
resourceServer Opcional El nombre del Resource Server registrado en el NAM, es para utilizar el
método de encriptado por defecto de ese Resource Server para el Access
Token.
grant_type Requerido El valor por defecto que se especifica es: authorization_code
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
client_secret Opcional El secret de la aplicación cliente que es obtenido durante el registro en el
NAM. Deberá ser opcional si la aplicación es nativa y mandatorio si es una
aplicación web.
code Requerido El código de autorización obtenido en la respuesta anterior.
redirect_uri Requerido Deberá ser el mismo valor que se envió en la petición para obtener el
código de autorización.
RESPONSE:
La respuesta se enviará a la uri de redirección enviada como parámetro en la petición anterior.
Parámetro Requerido Descripción
token_type Requerido El tipo de token generado, el NAM solo soporta “Bearer”.
access_token Requerido El Access Token que se utilizará para consumir las APIs del Resource Server
id_token Opcional Si se incluyó el scope de “OpenID” entonces se regresará también un ID
Token.
refresh_token Requerido El refresh token para renovar el Access Token.
scope Opcional La lista de todos los scopes autorizados por el usuario para ese cliente.
state Opcional El valor del estado enviado en la petición que se realizó para obtener el
código de autorización.
expires_in Requerido El tiempo en milisegundos de vida restante del Access Token.
EJEMPLO DE PETICIÓN Y RESPUESTA:
REQUEST
POST /nidp/oauth/nam/token HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Host: [Link]
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code &client_id=b017c96c-b16a-4d80-a5fa-68f5050abc58
&client_secret=ZDDwbuuWPdV_e5quAf7f0Jkg_iJJ7g &redirect_uri=[Link]
&code=/wEBAAk...................................
RESPONSE
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
{ "access_token":"/wEBAAQEACA......", "token_type":"bearer", "expires_in":179, "refresh_token":"/
wEBAAQEACA9lN8bgv..........", "scope":"email" }
AUTHORIZATION CODE WITH PKCE
Este grant tiene el mismo flujo que el Authorization Code sólo que ahora en vez de enviar un secret para
intercambiar un código por un token, se enviará un código de verificación y de desafio.
Obtener un código de autorización:
ENDPOINT: [Link]
MÉTODO: GET
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en
el NAM
response_type Requerido El valor por defecto que se especifica es: code.
redirect_uri Requerido Cualquier uri de redirección que fue registrada en el NAM para esa
aplicación cliente.
scope Requerido La lista de los scopes que la aplicación requiere, deberá contener
por lo menos el scope de “openid”, los scopes deberán ser
separados por “+” o “%20”.
resourceServer Opcional El nombre del Resource Server registrado en el NAM, es para
utilizar el método de encriptado por defecto de ese Resource
Server para el Access Token.
prompt Opcional none: para pedir un código sin tener que pedir autenticación al
usuario.
login: si se desea que el usuario se re-autentique.
consent: si se desea que el usuario vuelva a dar los permisos.
state Recomendado Un valor único definido por el cliente para mantener el estado
entre el request y el callback.
max_age Opcional Tiempo máximo en segundos de espera para que el usuario se
autentique.
acr_values Opcional Uri del contrato de NAM a mostrar.
code_challenge Requerido Código de desafío, con este parámetro se inicia el flujo de PKCE.
code_challenge_method Requerido El método con el cual se sacó el hash del código, valor por defecto:
S256
RESPONSE:
La respuesta se envía a la uri de redirección, el código de autorización estará ligado con el código de verificación.
Parámetro Requerido Descripción
code Requerido El código de autorización de longitud variable, el cliente no deberá asumir
la longitud del código.
state Requerido Contiene el estado enviado en el parámetro de la petición anterior.
EJEMPLO DE PETICIÓN:
HTTP/1.1 GET /nidp/oauth/nam/authz?code_challenge=WsEH2Rr4lWdciBEbCuHVlH_UIBUGFPRbDXcPsb-
Pl74&code_challenge_method=S256&scope=profile&response_type=code&redirect_uri=<<Redirec
URI>>&client_id=484fd33f-12b0-44c4-bbf5-82bae803b71d
Intercambiar el código de autorización por un ID Token y un Access Token, ahora se enviará un parámetro extra:
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
resourceServer Opcional El nombre del Resource Server registrado en el NAM, es para utilizar el
método de encriptado por defecto de ese Resource Server para el Access
Token.
grant_type Requerido El valor por defecto que se especifica es: authorization_code
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
code Requerido El código de autorización obtenido en la respuesta anterior.
redirect_uri Requerido Deberá ser el mismo valor que se envió en la petición para obtener el
código de autorización.
code_verifier Requerido Es requerido este campo debido a que el flujo de Authorization Code fue
inicializado en la petición anterior para usar PKCE.
RESPONSE:
Parámetro Requerido Descripción
token_type Requerido El tipo de token generado, el NAM solo soporta “Bearer”.
access_token Requerido El Access Token que se utilizará para consumir las APIs del Resource Server
id_token Opcional Si se incluyó el scope de “OpenID” entonces se regresará también un ID
Token.
scope Opcional La lista de todos los scopes autorizados por el usuario para ese cliente.
state Opcional El valor del estado enviado en la petición que se realizó para obtener el
código de autorización.
expires_in Requerido El tiempo en milisegundos de vida restante del Access Token.
EJEMPLO DE PETICIÓN Y RESPUESTA:
REQUEST
POST /nidp/oauth/nam/token?code=<<authorization code received from authorization endpoint>>
&grant_type=authorization_code&redirect_uri=<<Redirect URI>>&client_id=484fd33f-12b0-44c4-bbf5-
82bae803b71d&code_verifier=0ak1mD3loHOy1ZksmyoO1fQEhRBEuzGYbkQqKFe1Ny0
RESPONSE
HTTP/1.1 200 OK
{ "access_token":"/wEBAAQEACA......", "token_type":"bearer", "expires_in":179, "refresh_token":"/
wEBAAQEACA9lN8bgv..........", "scope":"email" }
EJEMPLO DE RESPUESTAS ERRONEAS:
{
"error": "invalid_grant",
"error_description": "Either invalid authorization code or invalid code verifier, PKCE verification failed"
}
{
"error": "invalid_grant",
"error_description": "PKCE verification failed because either code challenge is null or code challenge method is not
supported"}
IMPLICIT GRANT
Este flujo es ideal para aplicaciones cliente que viven en el dispositivo del usuario como puede ser una aplicación
móvil o una aplicación de escritorio. Con este flujo se puede solicitar autenticación de un usuario y además el
usuario puede dar autorización a una aplicación cliente para acceder a sus recursos. No se recomienda su uso.
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
response_type Requerido Si el valor es token entonces solo se genera un Access Token
Si el valor es id_token se genera solo el ID token
Si el valor es token+id_token se genera un Access Token y un ID Token .
redirect_uri Requerido Cualquier uri de redirección que fue registrada en el NAM para esa
aplicación cliente.
scope Requerido La lista de los scopes que la aplicación requiere, deberá contener por lo
menos el scope de “openid”, los scopes deberán ser separados por “+” o
“%20”.
resourceServer Opcional El nombre del Resource Server registrado en el NAM, es para utilizar el
método de encriptado por defecto de ese Resource Server para el Token.
prompt Opcional login: si se desea que el usuario se re-autentique
consent: si se desea que el usuario vuelva a dar los permisos a ese cliente.
state Recomendado Un valor único definido por el cliente para mantener el estado entre el
request y el callback.
max_age Opcional Tiempo máximo en segundos de espera para que el usuario se autentique.
acr_values Opcional Uri del contrato de NAM a mostrar.
RESPONSE:
Parámetro Requerido Descripción
token_type Requerido El tipo de token generado, el NAM solo soporta “Bearer”.
access_token Requerido El Access Token que se utilizará para consumir las APIs del Resource Server
id_token Opcional Si se incluyó en la petición anterior id_token o token+id_token entonces se
regresa el ID Token.
scope Opcional La lista de todos los scopes autorizados por el usuario para ese cliente.
state Opcional El valor del estado enviado en la petición que se realizó para obtener el
código de autorización.
expires_in Requerido El tiempo en milisegundos de vida restante del Access Token.
EJEMPLO DE PETICIÓN Y RESPUESTA:
[Link] authz?response_type=token+id_token&client_id=4e4ae330-1215-4fc8-9aa7-
79df8325451c&redirect_uri=[Link] callback&scope=email+OpenID&state=s1234&nonce=n123
RESPONSE
[Link] wEBAAUFACAjDfPtn d/zlOWPpN/
kV1Jtt3nxCPtzHyUH~&expires_in=3600&id_token=[Link] c3MiOiJo&scope=email&state=s1234
CLIENT CREDENTIALS
Este flujo es ideal para las aplicaciones cliente que accedan a sus propios recursos alojados en el Resource Server.
También es utilizado para autenticar a aplicaciones cliente en vez de usuarios ya que no se requieren las
credenciales de un usuario sino solo las de la aplicación cliente.
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
client_secret Requerido El secret de la aplicación cliente que es obtenido durante el registro en el
NAM.
grant_type Requerido El valor por defecto que se especifica es: client_credentials
scope Opcional La lista de los scopes que la aplicación requiere, los scopes deberán ser
separados por “+” o “%20”.
RESPONSE:
Parámetro Requerido Descripción
token_type Requerido El tipo de token generado, el NAM solo soporta “Bearer”.
access_token Requerido El Access Token que se utilizará para consumir las APIs del Resource Server
expires_in Requerido El tiempo en milisegundos de vida restante del Access Token.
EJEMPLO DE PETICIÓN Y RESPUESTA:
REQUEST
HTTP/1.1 POST /nidp/oauth/nam/token? &grant_type=client_credentials &client_id=bb775b12-bbd4-423b-83d9-
647aeb98608d &client_secret=bBbE-
4mNO_kWWAnEeOL1CLTyuPhNLhHkTThArEckyrdLmRLn3GhnxjsKI2mEijCSlPjftxHod_05dp-uGs6wA&scope=firmar
> User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
> Host: [Link]
> Accept: /
RESPONSE
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 630
{ "access_token": "/wEBAAAAACBy4Ku4ApcxEV7er19P6nqH5HZg5J6GcY...", "token_type": "bearer", "expires_in":3599 }
RESOURCE OWNER CREDENTIALS
En este flujo se requiere que la aplicación cliente sea quien reciba directamente las credenciales del usuario, luego
enviará las mismas junto con su ID y Secret al Authorization Server para obtener un Access Token, para este flujo
no se requiere que el usuario conceda los permisos al cliente.
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
client_secret Requerido El secret de la aplicación cliente que es obtenido durante el registro en el
NAM.
grant_type Requerido El valor debe ser: password
username Requerido El nombre de usuario del Resource Owner.
password Requerido La contraseña del Resource Owner.
scope Requerido Los scopes que solicitará la aplicación cliente.
RESPONSE:
Parámetro Requerido Descripción
token_type Requerido El tipo de token generado, el NAM solo soporta “Bearer”.
access_token Requerido El Access Token que se utilizará para consumir las APIs del Resource Server
expires_in Requerido El tiempo en milisegundos de vida restante del Access Token.
scope Requerido La lista de scopes que solicitó la aplicación cliente.
Refresh_token Requerido Un Refresh Token para poder obtener un nuevo Access Token.
EJEMPLO DE PETICIÓN Y RESPUESTA:
REQUEST
HTTP/1.1 POST /nidp/oauth/nam/token? &grant_type=password &client_id=bb775b12-bbd4-423b-83d9-647aeb98608d
&client_secret=bBbE-4mNO_kWWAnEeOL1CLTyuPhNLhHkTThArEckyrdLmRLn3GhnxjsKI2mEijCSlPjftxHod_05dp-uGs6wA
&username=user1 &password=pass@123 &scope=email%20profile
> Host: [Link]
> Accept: */*
RESPONSE
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 630
{ "access_token": "/wEBAAEBACAgHkphv9NdD5khH7CLty7PpURg9RKOQ5pm6...", "token_type" : "bearer", "expires_in" :
3599, "scope" : "profile email" }
EJEMPLO DE RESPUESTA INCORRECTA:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 143
{ "error" : "invalid_request", "error_description" : "OAuth Client Authentication Failure because password parameter is
missing in the request" }
REFRESH TOKEN ENDPOINT
El flujo de Implicit y Authorization Code requieren que el usuario esté disponible en el navegador y que tenga una
sesión activa con el servidor de autorización, es por eso que estos son flujos son llamados como flujos en línea.
Algunas veces la aplicación cliente necesitan acceder a los recursos protegidos aún cuando el usuario no está
disponible en línea y cuando se ha terminado el tiempo de vida de un Access Token, es cuando se utiliza un Refresh
Token para obtener un nuevo Access Token. Por lo general el tiempo de vida de un Refresh Token es más largo
que el de un Access Token. A éste flujo también se le conoce como flujo fuera de línea.
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
client_secret Requerido El secret de la aplicación cliente que es obtenido durante el registro en el
NAM.
grant_type Requerido El valor debe ser: refresh_token
refresh_token Requerido El refresh token obtenido en el flujo de Authorization Code, Implicit o
Resource Owner Credentials.
scope Requerido Los scopes autorizados para el Access Token original.
RESPONSE:
Parámetro Requerido Descripción
token_type Requerido El tipo de token generado, el NAM solo soporta “Bearer”.
access_token Requerido Un nuevo Access Token.
refresh_token Opcional Un nuevo refresh token.
scope Opcional La lista de todos los scopes autorizados por el usuario para ese cliente.
expires_in Requerido El tiempo en milisegundos de vida restante del Access Token.
EJEMPLO DE PETICIÓN Y RESPUESTA:
REQUEST
HTTP/1.1 POST /nidp/oauth/nam/token
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36
Host: [Link]
'grant_type=refresh_token &client_id=4e4ae330-1215-4fc8-9aa7-79df8325451c
&client_secret=Rxl5pvgL80DBzbIcLPVnH17FehZA8LLT7oZ9POFrEguEyB2JMzB6kBj3JH4BxpZTrnFSjmFgrCClQuCKt3MUg
&refresh_token=/wEBAAcHACAup9Kv@JZbLuBBaWeaYfkP/NT'
RESPONSE
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, no-transform
Content-Length: 0 Date: Tue, 03 Mar 2015 18:12:55 GMT
{ "access_token":"/wEBAAYGACBgyZapAgMYk7oJYXFO9/LIblf9FAnqp@Y1/Y/voByU9Z2awkCbfp
LZTzpUqFspZ4xrJc/TcNAl3hktfRDJgOUEHUkdyO/FoWxmTn3NrHL0K8kNPQo7nm3kyUSyjpxxvjVw
SOPtVmNl94AXOIxqObYpLoRgpqqeO8TUltvQlk9zMNkAmHscPTYFwMrzHE@B98kIrZ1b266eSbuAmL
r4y1guAx0yYs1XhboFd97I6mabGXDqeAjjpx/DTZBTCptA/LlIJgN10jMwik7x9nZZ3wjv16/4hw8G
UHaS09uHXqqtF3S0pJ6/aM/hsWAgkcZeOhliPGXV8T7tjMmc8V1t4mIzuOagzN0LbaclD1OBkndIKC
OcqJiiMMRDZNEHBjwoOXc~", "token_type":"bearer", "expires_in":3599, "scope":"profile email" }
INTROSPECTION TOKEN ENDPOINT
Con este endpoint se puede obtener toda la información de un Access Token o de un Refresh Token.
ENDPOINT: [Link]
MÉTODO: POST
HEADERS: Bearer: <Access_token>
REQUEST
Parámetro Requerido Descripción
token Requerido El token que se requiere saber la información. Solo se puede obtener
información de Access Tokens y de Refresh Tokens.
token_type_hint Opcional El tipo de token enviado.
RESPONSE
Parámetro Requerido Descripción
active Requerido Un valor boleano indicando si el token enviado está activo o no.
scope Opcional La lista de scopes autorizados para ese token.
client_id Opcional El client id de la aplicación cliente que solicitó ese token.
username Opcional El nombre de usuario que autorizó ese token.
token_type Opcional El tipo de token.
exp Opcional El tiempo en segundos que le queda de vida al token.
iat Opcional El timestamp en segundos de cuando fue generado ese token.
nbf Opcional El timestamp en segundos cuando el token ya no podrá ser utilizado.
sub Opcional Id del usuario que autorizó el token.
aud Opcional La audiencia a la que va dirigido ese token.
iss Opcional El servidor que generó ese token.
jti Opcional El identificador que tiene ese token.
TOKEN INFO ENDPOINT
Con este endpoint se puede obtener toda la información de un Access Token o de un Refresh Token.
ENDPOINT: [Link]
MÉTODO: POST
HEADERS: Bearer: <Access_token_a_validar>
RESPONSE
Parámetro Requerido Descripción
expires_in Requerido El tiempo en segundos que le queda de vida al token.
user_id Requerido El usuario quien autorizó ese token.
scope Requerido La lista de scopes autorizados para ese token..
REVOKE TOKEN ENDPOINT
Con este endpoint se puede revocar un Access Token enviando el Refresh Token. Este endpoint es útil en los
siguientes casos:
- Cuando un usuario cierra sesión en la aplicación cliente.
- Cuando una aplicación móvil o nativa es desinstalada.
- Para notificar al Authorization Server que el Refresh Token anterior ya no es necesario.
ENDPOINT: [Link]
MÉTODO: POST
REQUEST:
Parámetro Requerido Descripción
client_id Requerido El ID de la aplicación cliente que es obtenido durante el registro en el NAM
client_secret Opcional El secret de la aplicación cliente que es obtenido durante el registro en el
NAM. Es requerido cuando se trata de una aplicación web.
token Requerido El refresh token que fue obtenido durante el grant.
RESPONSE:
- El Authorization Server regresará un código http de respuesta 200 si el token se ha revocado
correctamente.
- Si el Authorization Server regresa un código http de respuesta 503 entonces la aplicación cliente no
deberá asumir que se ha revocado el token y deberá intentarlo de nuevo.
- Si se envía un refresh token incorrecto regresará la siguiente respuesta:
{ "error":"unsupported_token_type", "error_description":"Token other than refresh token cannot be sent for
revocation." }
USERINFO ENDPOINT
Con este endpoint se pueden obtener los atributos de un usuario que han sido autorizados para ese token.
ENDPOINT: [Link]
MÉTODO: GET
HEADERS: Bearer: <Access_token>
RESPONSE:
Parámetro Requerido Descripción
sub Requerido El GUID del usuario.
La lista de los Opcional
atributos
EJEMPLO DE PETICIÓN Y RESPUESTA:
REQUEST
HTTP/1.1 GET /nidp/oauth/nam/userinfo
HTTP/1.1 User-Agent: curl/7.41.0
Host: [Link]
Accept: /
Authorization: Bearer /wEBAA.............DSDG
RESPONSE
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Content-Length: 73
Date: Thu, 19 Mar 2018 16:14:52 GMT
{ "sub": "6adb7ca411d5a14c94946adb7ca411d5", "email": "alice@[Link]" }