URL externo y URL de autenticación de OAuth

• Cuando se autentican los propietarios de recursos, los metadatos sobre el propietario de recurso autenticado se deben almacenar en la señal de acceso.
• El tipo de otorgamiento utilizado para obtener la señal es otro ejemplo de metadatos almacenados dentro de la señal de acceso.
• Un código de confirmación que se debe enviar a la aplicación cliente conjuntamente con la señal de acceso se almacena como metadatos en la señal de acceso.

• External URL : al llamar a External URL, se envía una solicitud GET a HTTP y API Connect se espera un código de estado 200 OK de HTTP, junto con un conjunto opcional de los encabezados de respuesta especificados.
• Autenticación URL : cuando se llama a la interfaz de autenticación URL, la API Connect pasarela envía una solicitud GET con los encabezados HTTP y, a continuación, procesa cualquier respuesta HTTP procedente de URL. Para la autenticación, un servicio de autenticación de REST se espera en el URL de autenticación.

  Véase: Autenticación URL.

• DataPower® API Gateway:

  X-API-OAUTH-METADATA-FOR-PAYLOAD

  X-API-OAUTH-METADATA-FOR-ACCESSTOKEN

  Nota: Los encabezados anteriores son los nombres predeterminados para el DataPower API Gateway proveedor, pero puedes modificarlos; consulta «Configuración de metadatos para un proveedor nativo de OAuth ».
• DataPower Gateway (v5 compatible):

  API-OAUTH-METADATA-FOR-PAYLOAD

  API-OAUTH-METADATA-FOR-ACCESSTOKEN

{
"token_type":  "bearer",
"access_token":  "AAEkNzhjDHYyyYy...cL0Mv6ctl37w7ZU",
"metadata":  "m:metadata-for-payload_content"
"expires_in":  3600,
"scope":  "read",
"refresh_token":  "AAEnj5SynCMybF...oEZ6JjxYax_HdNg",
}

{
"active":  true,
"token_type":  "bearer",
"client_id":  "78c2f10f-799a-4e1f-8e0a-098634997a35",
"username":  "Fred Smith",
"sub":  "fred",
"exp":  1479850049,
"expstr":  "2016-11-22T21:27:29Z",
"iat":  1479846449,
"nbf":  1479846449,
"nbfstr":  2016-11-22T20:27:29Z",
"scope":  "read",
"miscinfo":  "m:metadata-for-accesstoken_content",
"client_name":  "MobileApp"
}

X-existing-metadata-for-payload     payload-from-auth-url
X-existing-metadata-for-access-token     token-from-auth-url
X-URI-in     /org/env/miscinfo/oauth2/token (the URL that was sent to APIConnect for this particular token request)
X-METHOD-in     POST
X-POST-Body-in     client_id=client_id&grant_type=password&scope=read&username=name&password=password
X-X-Client-IP     IP_address
X-X-Global-Transaction-ID     ID_number
...

apim.setvariable('message.body',apim.getvariable('oauth.miscinfo'));

Tipo de otorgamiento de código de autorización

• En un flujo de código de autorización de tres pasos, los metadatos del código de autenticación URL se almacenan en dp-state y se transfieren al código de autorización y al token de acceso. Se utilizan unos 10 caracteres internamente para diferenciar los metadatos de la carga útil de los metadatos del token de acceso cuando se almacenan en el dp-state. Además, si la revocación está habilitada, también forma parte de los metadatos del token. El tamaño total de los metadatos del token, los metadatos de la carga útil (incluidos los datos internos) y los detalles internos de revocación no puede superar los 512 bytes en total.

  Si el tamaño global de los metadatos supera los 512 bytes, la generación de la señal de acceso se realiza correctamente, pero los campos de metadatos contienen un mensaje de error de "metadata too large" como se muestra en el ejemplo.

  "metadata":"m:error: metadata too large for AZ code grant type[Authorization Code-metadata-url-payload]"
  "miscinfo":"[r:gateway]m:error: metadata too large for AZ code grant type[Authorization Code-metadata-url-token]"

  La restricción de tamaño no se aplica cuando los metadatos se envían desde el punto de fin de metadatos ( URL ) y no desde el punto de fin de autenticación ( URL ), ya que los metadatos no se almacenan en dp-state el código de autorización.

  Ejemplo del tipo de otorgamiento authorization code (access code) :

   $ curl -k -d
  "grant_type=authorization_code&code=$mycode&client_id=$myid&scope=scope_introspect&redirect_uri=" https://9.70.153.90/fei/sb/introspectp1/oauth2/token
  { "token_type":"bearer",
  "access_token":"AAEkOThlZDhhNjYtYTQ1ZS00YTMzLWE0N2QtZmE2OGZkMzQ0NzQ20ZN5Tl_TqYFeIfB7BFf6HFgibEoOjWXXEA84oFsWuE4NY-RRZVdnGSaXAIYJz7s5vczfk5EV-BIb_6P_1YKm3ahrfhR5kI3sPO0uADEoseIP5-O9anUpEM5yhsayXvZbJ_6VDYz-hyXSJHTNqVj-PHBialoRkBD5qca6kO0fV2M", "metadata":"a:[Authorization Code-Test-auth-url-payload]", "expires_in":3600, "scope":"scope_introspect", "refresh_token":"AAFAg1EVMbwicr_L0fTZ4q6HZ-RcQygniXFC9zbSKO4wd3hcniC4KQX21X0fL2c8cnmzCZgws8xxLzNyfjQhUJNGl5C1GbIe3dwhXJdiWA0Go-dduhVtCbG26sJRRXyYrMeRxWnJsylBETPI8HQEN4a_D7fmxKcTVRZBvq86byg95qe1ZKyERi0Lhxdd_O4Nvss" }
  
  
  $ curl -k -H "X-IBM-Client-Id: $myid" -H "X-IBM-Client-Secret: $mysecret" -d "token_type_hint=access_token&token=$mytoken" https://9.70.153.90/fei/sb/introspectp1/oauth2/introspect
  { "active":true, "token_type":"bearer", "client_id":"98ed8a66-a45e-4a33-a47d-fa68fd344746", "username":"anyuser", "sub":"anyuser", "exp":1484766368, "expstr":"2017-01-18T19:06:08Z", "iat":1484762768, "nbf":1484762768, "nbfstr":"2017-01-18T18:06:08Z", "scope":"scope_introspect", "miscinfo":"[r:gateway]a:[Authorization Code-Test-auth-url-token]", "client_name":"oauth_app" }

Tipo de otorgamiento implícito

• Cuando se utiliza el tipo de otorgamiento implícito, la señal de acceso y los metadatos se devuelven en la cabecera location como un fragmento, tal como puede ver en el ejemplo.

  < Location:
   https://localhost#access_token=AAEkOThlZDhhNjYtYTQ1ZS00YTMzLWE0N2QtZmE2OGZkMzQ0NzQ2buS2KfWdq-nYBJSi4nmPxQBtLae17tKBPRMzwP5BC386nlxpoOTE1G748ZVH6Mq_TJL3GeV3PtXTVIkWOLBJi_7tljiQfpnVfrNkovvZkhUexYmFkcDsmLSdaWxZ6PcIMPAC4ojT8qV1sYV-ChTk36yqOx_NiKimZaDikDk7WTg&expires_in=3600&scope=scope_introspect&token_type=bearer&metadata=a%3A[Implicit-Test-auth-url-payload]
  
  $ curl -k -H "X-IBM-Client-Id: $myid" -H "X-IBM-Client-Secret: $mysecret" -d "token_type_hint=access_token&token=$mytoken" https://9.70.153.90/fei/sb/introspectp1/oauth2/introspect
                { "active":true, "token_type":"bearer", "client_id":"98ed8a66-a45e-4a33-a47d-fa68fd344746", "username":"anyuser", "sub":"anyuser", "exp":1484768365, "expstr":"2017-01-18T19:39:25Z", "iat":1484764765, "nbf":1484764765, "nbfstr":"2017-01-18T18:39:25Z", "scope":"scope_introspect", "miscinfo":"[r:gateway]a:[Implicit-Test-auth-url-token]", "client_name":"oauth_app" }
  

Tipo de otorgamiento de credenciales de cliente:

La autenticación URL no se puede iniciar cuando se utiliza el tipo de concesión «credenciales de cliente», ya que no hay ningún propietario del recurso. Los metadatos del URL de autenticación no están disponibles para este tipo de otorgamiento. Sin embargo, el contenido devuelto por Metadata URL se incluye como metadatos.