Si hallas algún error con tu código o proyecto, recuerda probar siempre en un entorno de testing antes añadir el código al trabajo final.
Solución:
Esta es una buena pregunta: hay mucha confusión en torno a los tokens y OAuth.
En primer lugar, cuando menciona OAuth, probablemente se esté refiriendo al estándar OAuth2. Esta es la última versión del protocolo OAuth, y es de lo que la mayoría de la gente habla específicamente cuando dice ‘OAuth’.
El protocolo OAuth admite varios tipos diferentes de autenticación y autorización (4 para ser precisos).
En segundo lugar, el protocolo OAuth funciona autenticando a los usuarios a través de tokens. La idea aquí es esta:
En lugar de que su usuario envíe sus credenciales reales a su servidor en cada solicitud (como lo haría con la Autenticación básica, donde un usuario envía su nombre de usuario/contraseña al servidor para cada solicitud), con OAuth primero intercambia sus credenciales de usuario por una ‘token’, y luego autenticar a los usuarios en función de este ‘token’.
La idea de OAuth es que al requerir que los usuarios pasen sus credenciales confidenciales a través de la red con menos frecuencia, pueden ocurrir menos cosas malas. (Esta es la idea, de todos modos.)
Ahora, aquí es donde entran en juego los tokens: la especificación de OAuth se basa en el concepto de tokens, pero NO ESPECIFICA QUÉ ES UN TOKEN.
En el sentido más ‘general’, un token es solo un string que identifica de forma única a un usuario. Eso es todo.
La gente se dio cuenta de esto y desarrolló un nuevo estándar para crear tokens, llamado el estándar JSON Web Token. Este estándar básicamente proporciona un conjunto de reglas para crear tokens de una manera muy específica, lo que hace que los tokens sean más útiles para usted en general.
Los JWT te permiten hacer cosas como:
- Firme criptográficamente un token para que sepa que un usuario no lo manipuló.
- Cifrar tokens para que el contenido no se pueda leer en texto sin formato.
- Incrustar datos JSON DENTRO de un token string de manera estándar.
Ahora, en su mayor parte: casi todos en la comunidad de desarrollo han acordado que si está usando algún tipo de OAuth, entonces los tokens que está usando deben ser tokens web JSON.
==========
¡DE ACUERDO! Ahora que hemos cubierto la historia de fondo, déjame responder a tu pregunta.
La elección que está haciendo arriba es si desea o no habilitar la especificación completa de OAuth2 para la autenticación/autorización (que es bastante compleja), o si simplemente desea una ‘autenticación de token’ básica.
Debido a que el protocolo OAuth proporciona múltiples formas diferentes de autenticación de una manera CUMPLIDA CON LOS ESTÁNDARES, agrega mucha complejidad a la mayoría de los sistemas de autenticación.
Debido a esto, muchos marcos ofrecen una versión ‘simplificada’ del flujo OAuth2 Password Grant, que esencialmente es un método simple donde:
- Un usuario envía su nombre de usuario/contraseña a su servidor en alguna URL como /login.
- Su servidor genera un token JWT para el usuario.
- Su servidor devuelve ese token al usuario.
- El usuario almacena este token en sus cookies, dispositivo móvil o posible servidor API, donde lo utiliza para realizar solicitudes.
Nuevamente: el flujo anterior NO es compatible con OAuth, pero es una versión un poco más simple que TODAVÍA usa tokens.
El punto principal aquí es que los tokens (JWT) son generalmente útiles y NO NECESITAN estar emparejados con el flujo de OAuth.
Me doy cuenta de que esto es un muro de texto, pero espero que responda a su pregunta con más profundidad =)
Cuando solicita un recurso de un servicio web seguro, puede proporcionar un token de autenticación en la llamada. El token actúa como “código secreto” para acceder al recurso.
OAuth es solo un tipo específico de método de autenticación basado en token.
OAuth es una especificación para la autorización, no para la autenticación.
OAuth 2.0 es una especificación para autorización, pero NO para autenticación. RFC 6749, 3.1. Authorization Endpoint explícitamente dice lo siguiente:
El extremo de autorización se utiliza para interactuar con el propietario del recurso y obtener una concesión de autorización. El servidor de autorizaciones DEBE primero verificar la identidad del propietario del recurso. La forma en que el servidor de autorización autentica al propietario del recurso (por ejemplo, inicio de sesión con nombre de usuario y contraseña, cookies de sesión) es más allá del alcance de esta especificación.
Solo use OAuth si desea dar acceso a un servicio de terceros a sus API. Incluso cuando usa OAuth, necesitaría algún tipo de autenticación (basada en token o basada en sesión, etc.) para autenticar los usos. OAuth no está diseñado para la autenticación.
ver esta pregunta.