{"id":71307,"date":"2020-02-24T22:18:55","date_gmt":"2020-02-24T19:18:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt"},"modified":"2020-03-03T16:14:27","modified_gmt":"2020-03-03T13:14:27","slug":"identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Conceptos b\u00e1sicos. OpenID Connect, OAuth 2.0 y JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Con este post, quiero abrir una serie de art\u00edculos dedicados a IdentityServer4. Comenzaremos con los conceptos b\u00e1sicos.<\/p>\n

<\/p>\n

El protocolo de autenticaci\u00f3n m\u00e1s prometedor en la actualidad es OpenID Connect<\/a><\/noindex>, y el protocolo de autorizaci\u00f3n (provisi\u00f3n de acceso) es OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementa estos dos protocolos. Est\u00e1 optimizado para resolver problemas t\u00edpicos<\/strong> de seguridad.<\/p>\n

<\/a><\/noindex><\/p>\n

OpenID Connect<\/a><\/noindex> \u2014 es un protocolo y est\u00e1ndar de autenticaci\u00f3n, no otorga acceso a recursos (Web API), pero dado que est\u00e1 dise\u00f1ado sobre un protocolo de autorizaci\u00f3n OAuth 2.0<\/a><\/noindex>, permite obtener los par\u00e1metros del perfil del usuario como si hubieras accedido al recurso UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) es un est\u00e1ndar web que define la forma de transmitir datos del usuario en formato JSON de manera encriptada.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 es un protocolo y est\u00e1ndar de autorizaci\u00f3n. Permite a las aplicaciones acceder a recursos protegidos, como Web API.<\/p><\/blockquote>\n

Veamos el diagrama de acceso a un recurso protegido y analicemos los pasos principales y la terminolog\u00eda adoptada:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    El cliente solicita al usuario permiso para autorizar en su nombre. Cliente<\/strong> \u2014 es la aplicaci\u00f3n cliente que accede a los recursos protegidos en nombre del propietario de los recursos. El recurso<\/strong> \u2014 son todos nuestros servicios protegidos Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    El usuario permite a la aplicaci\u00f3n cliente autorizar en su nombre, por ejemplo, ingresando su nombre de usuario y contrase\u00f1a. El nombre de usuario y la contrase\u00f1a servir\u00e1n como el grant de autorizaci\u00f3n para la aplicaci\u00f3n cliente. User (propietario de recursos)<\/strong> \u2014 es el programa o persona que puede otorgar acceso a recursos protegidos, por ejemplo, ingresando el nombre de usuario (username) y la contrase\u00f1a (password);<\/p>\n

    \n<\/li>\n

  3. \n

    La aplicaci\u00f3n cliente solicita un token de acceso a IdentityServer4<\/code> proporcionando informaci\u00f3n sobre s\u00ed misma (client_id<\/code>, client_secret<\/code>), otorgando permiso de autorizaci\u00f3n por parte del usuario (username<\/code>, password<\/code>) y presentando grant_type<\/code> y scope<\/code>. Luego, el servidor de autorizaci\u00f3n verifica la autenticidad del cliente y las credenciales del propietario de recursos (nombre de usuario y contrase\u00f1a). <\/p>\n

    <\/p>\n

    El protocolo OAuth 2.0 no solo autentica al usuario, sino tambi\u00e9n a la aplicaci\u00f3n cliente que accede a los recursos. Para ello, el protocolo contempla par\u00e1metros como client_id<\/strong> y client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 es el identificador de la aplicaci\u00f3n cliente utilizado IdentityServer4<\/code> para buscar informaci\u00f3n sobre el cliente.
    \nclient_secret<\/strong> es un equivalente de la contrase\u00f1a para la aplicaci\u00f3n cliente y se utiliza para autenticar la aplicaci\u00f3n cliente en IdentityServer4<\/code>. el secreto del cliente debe ser conocido solo por la aplicaci\u00f3n y la API<\/strong>. A partir de lo anterior, concluimos que IdentityServer4 debe conocer a sus clientes<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Si la autenticidad de la aplicaci\u00f3n se confirma y el permiso de autorizaci\u00f3n es v\u00e1lido, IdentiryServer4<\/code> crea un token de acceso<\/code> para la aplicaci\u00f3n y un token de actualizaci\u00f3n opcional (refresh-token<\/code>). El proceso de autorizaci\u00f3n ha finalizado. Si la solicitud es inv\u00e1lida o no autorizada, el servidor de autorizaci\u00f3n devuelve un c\u00f3digo con el mensaje de error correspondiente.<\/p>\n

    \n<\/li>\n

  5. \n

    La aplicaci\u00f3n cliente solicita datos a la API web protegida, proporcionando el token de acceso para la autorizaci\u00f3n. Si el c\u00f3digo de respuesta del servidor de recursos 401<\/a><\/noindex>, 403<\/a><\/noindex> o 498<\/a><\/noindex>, el token de acceso utilizado para la autenticaci\u00f3n es inv\u00e1lido o ha expirado.<\/p>\n

    \n<\/li>\n

  6. \n

    Si el token es v\u00e1lido, Web API<\/code> proporciona los datos a la aplicaci\u00f3n.<\/p>\n

    \n<\/li>\n<\/ol>\n

    <\/p>\n

    Tipos de tokens<\/em><\/h4>\n

    <\/p>\n

    Se permite a los clientes registrados solicitar IdentityServer4<\/code> identity IdentityServer4<\/code> -token,<\/code>access -token y<\/code>refresh -token.<\/code>identity-token (token de identificaci\u00f3n)<\/p>\n

    <\/p>\n