OAuth2 y autenticación

1.What is the difference between authentication and authorization?

Autenticación es el proceso mediante el cual un servidor comprueba si un usuario es realmente el usuario que afirma ser. Esto generalmente se hace cuando el usuario proporciona el nombre de usuario y una contraseña, mientras que el servidor verifica estas credenciales (nombre de usuario, contraseña) con las almacenadas en su base de datos, cuando el primer usuario creó su cuenta. Autorización es cuando una entidad otorga permiso a otra entidad para realizar una acción. En este caso, por ejemplo, es cuando un sitio quiere acceder a los datos de un usuario, que están almacenados y son propiedad de un sitio web diferente.

2.What is OAuth2 meant to do?

Oficialmente, OAuth2 permite a un usuario permitir que un sitio web C del cliente acceda a sus datos desde un sitio web de servidor de recursos RS después de la autenticación a través de un sitio web de servidor de autenticación AS. Esto parece bastante complejo, por lo que para simplificar, un ejemplo común es cuando un usuario inicia sesión en un sitio web con su cuenta de Facebook. En ese caso, el sitio web del cliente y el sitio web del servidor de recursos son los mismos (C = RS = el sitio web visitado) y el servidor de autenticación es facebook (AS = facebook). Tenga en cuenta que esto se creó para que la C, RS no aprenda la contraseña del usuario y pueda autenticarlo.

3.WhyisOAuth2implicitflowinsecureforauthenticationwhilestillsecureforauthorization?

Laespecificidadconelflujoimplícitoeselhechodequeeltokendeaccesoseentregaalagentedeusuarioparareenviarloalaaplicación.Porlotanto,sebasaúnicamenteenlaredireccióndeURI.Porlotanto,esteflujonoautenticalaidentidaddelaaplicación,yaquenohayconfidencialidadsecretadelcliente(tokendeaccesoexpuestoalusuarioylasaplicacionesqueseejecutanenelmóvil)

4.WhatisthedifferencebetweenOAuth2implicitflowandOauth2authenticationcodeflowandwhentousewhich?

Comosedescribióanteriormente,enelflujoimplícitoeltokendeaccesoesenviadoalaaplicaciónporelagentedeusuario.Porotrolado,enelflujodecódigodeautorización,elservidorwebclienteobtieneprimerouncódigodeautorización(despuésdequeelPropietariodelrecurso/usuariodioacceso),luegorealizaunallamadaalaAPIquepasa(clientID,secretID)conelcódigodeautorizaciónparaobtenerlatokendeacceso.Estosehace,demodoqueenelcasodeconexionesHTTP(sincifradoSSL),eltokendeaccesonoesaccesibleparaeladministrador(enrutadores,servidoresproxy,etc.).Porlotanto,elprimeroesadecuadoparaaplicacionesmóviles,mientrasqueelsegundoesadecuadoparaaplicacionesdelladodelservidor.

5.DoesOAuth2authenticationcodeflowworkforauthentication?

Sí,elflujodelcódigodeautorizacióntambiénautenticaalusuarioatravésdelservidordeautenticación.

6.ShouldyouuseOpenIDinsteadofOAuth2forauthentication?

Sí.

OpenIDseutilizaparalaautenticación.Unejemploescuandoqueremosquelosusuariospuedaniniciarsesiónenvariossitioswebconunúnicoconjuntodecredenciales(iniciodesesión).

OAuthseutilizaparalaautorización,comosedescribeanteriormente.TengaencuentaqueOAuthpuedeajustarseligeramente(comoenelejemploanterior,dondeC=RS)pararealizar(pseudo)autenticaciónmedianteunaautorización.Pero,sisoloqueremosautenticación,podemosusarOpenID.

7.Whyisgooglesayingthattheir"OAuth2" framework can be used for both authentication and authorization.

Supongo que las razones reales detrás de esta decisión de diseño solo pueden ser dadas por los ingenieros de Google correspondientes, pero puedo suponer que en lugar de usar tanto OpenID como OAuth, seleccionaron usar un solo protocolo para ambos usos, para simplificar cosas. Sin embargo, tenga en cuenta el hecho de que la autenticación a través de OAuth se realiza mediante la autenticación de alguien, a través de los datos que posee. Un ejemplo aburrido sería que cuando intento ingresar al edificio de mi trabajo, no me preguntan por mis credenciales, porque mi tarjeta de empleado está obviamente en mi cuello. Así es como se realiza la autenticación a través de OAuth, bastante simplificada. Entonces, puede ver que esto puede hacer varias suposiciones que no siempre se sostienen en cada escenario. Y esta es la razón por la que generalmente se recomienda usar OAuth solo para la autorización y el uso de OpenID, en caso de que también necesite implementar la autenticación.

Un buen enlace que describe los diversos flujos de OAuth para reference

@RaptisDimos dio una buena respuesta pero creo que gastaré en el punto # 3.

  

3. ¿Por qué el flujo implícito OAuth2 es inseguro para la autenticación y al mismo tiempo es seguro para la autorización?
  

El problema con el flujo implícito cuando intenta usarlo para la autenticación es que el cliente recibe directamente un token de acceso y que el token de acceso no está vinculado a ningún cliente específico. Lo que esto significa es que el cliente no sabe si este token fue para él u otra aplicación.

Este token se usa para acceder a los datos del propietario. Cuando quiere "autenticar" al propietario, generalmente retira su correo electrónico de sus datos y lo autentica en su aplicación (cliente). Pero, no sabe quién le pasó ese token de acceso a su cliente. ¿Fue el propietario real o un atacante que aloja otro servicio?

Ejemplo de un ataque

• Client_Good: un buen cliente que usa la API de Google para autenticar a su usuario mediante el flujo implícito
• Client_Bad: un cliente malicioso que usa la API de Google y ataca a Client_Good

Client_Bad puede ser cualquier servicio. Por ejemplo, una aplicación web que te permite cargar imágenes en tu disco de Google. Para lograr esa tarea, Client_Bad necesita un token de acceso de Google. Así que le pedirá que le proporcione uno. Luego, podrá utilizar su servicio para cargar su imagen.

Lo que no sabías es que el token de acceso que acabas de darle a Client_Bad para cargar imágenes también es un token de acceso válido que podría usarse con Client_Good para autenticarse. Ahora, el propietario de Client_Bad puede suplantarlo en Client_Good. Si Client_Good fuera un servicio crítico, podría estar en un problema grave.

¿Por qué es seguro para la autorización entonces?

Es seguro porque si le das la autorización a Client_Bad para que suba una foto en tu nombre, no importa si lo está haciendo directamente o si está pasando por otro servicio para hacerlo.

Por ejemplo, podría haber un tercer cliente, Client_Picture, que también acaba de cargar una imagen en su unidad de Google. Cuando le pides a Client_Bad que cargue tus cosas, Client_Bad podría delegar esa tarea a Client_Picture y no te importaría si logra el mismo resultado.

Bueno, existe el hecho de que ahora una tonelada de terceros podría tener acceso a sus datos, pero nuevamente, estuvo de acuerdo en que Client_Bad podría hacer lo que quisiera con este token de acceso cuando se lo dio. Es como pasarle la llave de sus autos a su vecino. Usted le dio a otra persona el derecho de usar ese auto, él podría prestárselo a otro vecino por un tiempo y luego devolvérselo. La cosa es que no lo sabes y "aceptaste" eso cuando le diste el control.

Nota : a veces me pregunto si alguien entiende la explicación o si dije algo mal ... De todos modos, se explica en la sección 10.16 de la especificación OAuth2 en otras palabras, si eso ayuda.