{"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\/pt\/blog\/administrirovanie\/identityserver4-osnovnye-ponyatiya-openid-connect-oauth-2-0-i-jwt","title":{"rendered":"IdentityServer4. Conceitos b\u00e1sicos. OpenID Connect, OAuth 2.0 e JWT","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Com este post, quero abrir uma s\u00e9rie de artigos dedicados ao IdentityServer4. Come\u00e7aremos pelos conceitos b\u00e1sicos.<\/p>\n

<\/p>\n

Atualmente, o protocolo de autentica\u00e7\u00e3o mais promissor \u00e9 OpenID Connect<\/a><\/noindex>, e o protocolo de autoriza\u00e7\u00e3o (concess\u00e3o de acesso) \u00e9 OAuth 2.0<\/a><\/noindex>. IdentityServer4<\/a><\/noindex> implementa esses dois protocolos. Ele \u00e9 otimizado para resolver problemas t\u00edpicos<\/strong> de seguran\u00e7a.<\/p>\n

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

OpenID Connect<\/a><\/noindex> \u2014 \u00e9 um protocolo e padr\u00e3o de autentica\u00e7\u00e3o, n\u00e3o concede acesso a recursos (Web API), mas como foi desenvolvido sobre o protocolo de autoriza\u00e7\u00e3o OAuth 2.0<\/a><\/noindex>, permite obter os par\u00e2metros do perfil do usu\u00e1rio como se voc\u00ea tivesse obtido acesso ao recurso UserInfo<\/a><\/noindex>.<\/p>\n

JWT<\/a><\/noindex> (JSON Web Token) \u00e9 um padr\u00e3o da web que define como transmitir dados sobre o usu\u00e1rio em formato JSON de forma criptografada.<\/p>\n

OAuth 2.0 (RFC 6749)<\/a><\/noindex> \u2014 \u00e9 um protocolo e padr\u00e3o de autoriza\u00e7\u00e3o. Ele permite que aplicativos acessem recursos protegidos, por exemplo, Web APIs.<\/p><\/blockquote>\n

Vamos dar uma olhada no diagrama de acesso a um recurso protegido e entender os passos principais e a terminologia aceita:<\/p>\n

<\/p>\n

\"IdentityServer4.<\/p>\n

<\/p>\n

    \n
  1. \n

    O cliente solicita ao usu\u00e1rio permiss\u00e3o para se autenticar em seu nome. Cliente<\/strong> \u2014 \u00e9 um aplicativo cliente que acessa recursos protegidos em nome do propriet\u00e1rio dos recursos. Recurso<\/strong> \u2014 s\u00e3o todos os nossos servi\u00e7os protegidos Web API<\/a><\/noindex>.<\/p>\n

    \n<\/li>\n

  2. \n

    O usu\u00e1rio permite que o aplicativo cliente se autentique em seu nome, por exemplo, inserindo um login e uma senha. O login e a senha servir\u00e3o como concess\u00e3o de autoriza\u00e7\u00e3o para o aplicativo cliente. Usu\u00e1rio (propriet\u00e1rio do recurso)<\/strong> \u2014 \u00e9 um programa ou pessoa que pode conceder acesso a recursos protegidos, por exemplo, inserindo um login (username) e uma senha (password);<\/p>\n

    \n<\/li>\n

  3. \n

    O aplicativo cliente solicita um token de acesso ao IdentityServer4<\/code> fornecendo informa\u00e7\u00f5es sobre si mesmo (client_id<\/code>, client_secret<\/code>), fornecendo a permiss\u00e3o de autoriza\u00e7\u00e3o do usu\u00e1rio (nome de usu\u00e1rio<\/code>, senha<\/code>) e fornecendo grant_type<\/code> e scope<\/code>. Em seguida, o servidor de autoriza\u00e7\u00e3o verifica a autenticidade do cliente e as credenciais do propriet\u00e1rio do recurso (login e senha). <\/p>\n

    <\/p>\n

    O protocolo OAuth 2.0 realiza a autentica\u00e7\u00e3o n\u00e3o apenas do usu\u00e1rio, mas tamb\u00e9m do aplicativo cliente que acessa os recursos. Para isso, o protocolo prev\u00ea par\u00e2metros como client_id<\/strong> e client_secret<\/strong>.
    \nclient_id<\/strong> \u2014 \u00e9 o identificador do aplicativo cliente, utilizado IdentityServer4<\/code> para procurar informa\u00e7\u00f5es sobre o cliente.
    \nclient_secret<\/strong> \u00e9 o equivalente \u00e0 senha para o aplicativo cliente e \u00e9 usado para autenticar o aplicativo cliente na IdentityServer4<\/code>. O segredo do cliente deve ser conhecido apenas pelo aplicativo e pela API<\/strong>. Com base no exposto, podemos concluir que IdentityServer4 deve estar ciente de seus clientes<\/strong>.<\/p><\/blockquote>\n

    \n<\/li>\n

  4. \n

    Se a autenticidade do aplicativo for confirmada e a autoriza\u00e7\u00e3o for v\u00e1lida, IdentiryServer4<\/code> cria um token de acesso<\/code> (token de acesso) para o aplicativo e uma chave de atualiza\u00e7\u00e3o opcional (refresh-token<\/code>). O processo de autoriza\u00e7\u00e3o est\u00e1 conclu\u00eddo. Se a solicita\u00e7\u00e3o for inv\u00e1lida ou n\u00e3o autorizada, o servidor de autoriza\u00e7\u00e3o retorna um c\u00f3digo com a mensagem de erro correspondente.<\/p>\n

    \n<\/li>\n

  5. \n

    O aplicativo cliente solicita dados da API Web protegida, fornecendo o token de acesso para autoriza\u00e7\u00e3o. Se o c\u00f3digo de resposta do servidor de recursos 401<\/a><\/noindex>, 403<\/a><\/noindex> ou 498<\/a><\/noindex>, o token de acesso usado para autentica\u00e7\u00e3o \u00e9 inv\u00e1lido ou expirou.<\/p>\n

    \n<\/li>\n

  6. \n

    Se o token for v\u00e1lido, Web API<\/code> fornece dados para o aplicativo.<\/p>\n

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

    <\/p>\n

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

    <\/p>\n

    Clientes registrados t\u00eam permiss\u00e3o para solicitar IdentityServer4<\/code> tokens de identidade, IdentityServer4<\/code> identidade<\/code>-token, access<\/code>-token e refresh<\/code>-token.<\/p>\n

    <\/p>\n