OAuth 2.0 - Notas de desarrollo del servicio de autorización (1)

1. Concepto

OAuth es un estándar de red abierta sobre autorización, que se usa ampliamente en todo el mundo. La versión actual es la versión 2.0. La versión 1.0 se abandonó debido a su diseño engorroso.

 El protocolo OAuth proporciona un estándar seguro y sencillo para la autorización de recursos de usuario. La diferencia con el método de autorización anterior es que la autorización OAuth no permitirá que un tercero toque la información de la cuenta del usuario (como el nombre de usuario y la contraseña), es decir, el tercero puede solicitar los recursos del usuario sin utilizar el usuario. nombre y contraseña Autorización, por lo que OAuth es seguro. OAuth es la abreviatura de autorización abierta

No existe una implementación estándar de OAuth en sí, y los desarrolladores de back-end lo implementan de acuerdo con las necesidades reales y las regulaciones estándar. Los pasos son generalmente los siguientes:

1. El tercero requiere que el usuario otorgue la autorización
2. El usuario acepta la autorización
3. De acuerdo con la autorización obtenida en el paso anterior, el tercero solicita un token del servidor de autenticación
4. El servidor de autenticación autentica la autorización y emite el token después de confirmar que es correcto
5. El tercero usa el token para solicitar recursos del servidor de recursos
6. El servidor de recursos usa el token para confirmar la corrección del token al servidor de autenticación y proporciona recursos después de la confirmación

 

2. Miembros de OAuth:

1.Propietario del recurso (propietario del recurso: usuario)
2.Cliente (plataforma de acceso de terceros: solicitante)
3.Servidor de recursos (recurso del servidor: centro de datos)
4.Servidor de autorización (servidor de autenticación)

 

3. Flujo de ideas

OAuth establece una capa de autorización entre el "cliente" y el "proveedor de servicios". El "cliente" no puede iniciar sesión directamente en el "proveedor de servicios", sino que solo puede iniciar sesión en la capa de autorización, para distinguir al usuario del cliente. El token (token) que utiliza el “cliente” para iniciar sesión en la capa de autorización es diferente a la contraseña del usuario. Al iniciar sesión, el usuario puede especificar el alcance del permiso y el período de validez del token de la capa de autorización.
Después de que el "cliente" inicie sesión en la capa de autorización, el "proveedor de servicios" abre los datos almacenados del usuario al "cliente" de acuerdo con el alcance de la autoridad y el período de validez del token.

Pasos de autorización:

①Solicitud de autorización, el tercero solicita la autorización del usuario
②Concesión de autorización, una vez que el usuario acepta la autorización, se obtendrá una credencial de autorización de usuario única (como un código de código) del proveedor de servicios para el tercero ③Concesión de autorización, el
tercero le dará la credencial de autorización y el proveedor de servicios Las credenciales de identidad (como AppId) se entregan a la parte del servicio para solicitar un token de acceso
④Token de acceso del servidor de autenticación, y el servidor de autenticación verifica las credenciales de autorización y otra información
. El token de acceso solicita datos al servidor de recursos
⑥ Recurso protegido, y el servidor de recursos usa el token para confirmar la corrección del token al servidor de autenticación y proporciona el recurso después de confirmar que es correcto. De esta manera,
    la parte del servicio puede confirmar que el tercero ha obtenido la autorización del usuario para este servicio (según las credenciales de autorización del Usuario), segundo, se puede determinar que se puede confiar en la identidad del tercero (según las credenciales de identidad), por lo que el resultado final es que el tercero obtuvo con éxito el servicio solicitado del proveedor de servicios. Del proceso anterior, se
    puede ver que OAuth2.0 resuelve completamente el problema de confianza entre el usuario, el proveedor de servicios y el tercero en un determinado servicio.

4. Tipo de autorización:

En la autorización abierta, la aplicación de terceros (Cliente) puede ser un sitio web, una pieza de código JavaScript que se ejecuta en un navegador o un programa de aplicación instalado localmente. Estas aplicaciones de terceros tienen sus propias funciones de seguridad. Para el sitio web, está separado del navegador RO, y puede guardar datos confidenciales en el protocolo por sí mismo, y es posible que estas claves no estén expuestas al RO; para el código JavaScript y las aplicaciones de seguridad locales, se ejecuta en el navegador RO, RO son los datos confidenciales a los que puede acceder el Cliente en el protocolo.

OAuth tiene varios tipos de autorización, como concesión de código de autorización, concesión implícita, concesión de credenciales de RO (concesión de credenciales de contraseña del propietario del recurso) y concesión de credenciales de cliente.

 

5. Actualice el token:

Si el token de acceso del cliente access_token ha caducado cuando el usuario lo visita, debe usar el token de actualización refresh_token para solicitar un nuevo token de acceso. El cliente emite una solicitud HTTP para renovar el token, que contiene los siguientes parámetros:

granttype: indica el modo de autorización utilizado, y el valor aquí se fija como "refreshtoken", que es obligatorio.
refresh_token: Indica el token de actualización recibido anteriormente, requerido.
scope: Indica el alcance de autorización de la solicitud, el cual no puede exceder el alcance de la solicitud anterior, si se omite este parámetro, significa que es consistente con la solicitud anterior.

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

6. Caso de referencia

Autenticación Oauth2.0 de Facebook:

第一步:

App向 Oauth Server 请求的URL => https://facebook.com/dialog/oauth?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=REDIRECT_URI&scope=email

里面带着该app的id,key,请求的类型,返回一串的access_token和事件类型code。

第二步:

回调,跳转到权限确认页面等待用户确认授权 => https://facebook.com/dialog/oauth?response_type=code&client_id=28653682475872&redirect_uri=example.com&scope=email

该页面通过redirect_uri,回调到指定的callback页面。

第三步:

利用返回的access_token,将app的id和key以及code代码发包到:POST https://graph.facebook.com/oauth/access_token

这一步是为了获取token。

第四步:

Oauth Server返回token,这个时候,就可以通过token获取用户授权的资源了。

 

Documentos de referencia:

https://segmentfault.com/a/1190000000758580

https://segmentfault.com/a/1190000010540911

Supongo que te gusta

Origin blog.csdn.net/sm9sun/article/details/88309114
Recomendado
Clasificación