Cómo forzar el vencimiento del token de acceso OAuth2 con DotNetOpenAuth

Question

Estoy implementando el servidor de autorización/recursos OAuth2 basado en DotNetOpenAuth. Mi servidor emitirá tokens de acceso con un tiempo de vida muy largo. Estos tokens se usarán desde dispositivos iOS. El flujo, de la forma en que lo veo, es así: 1) se le pide al usuario que ingrese su nombre de usuario/contraseña en el dispositivo iOS 2) se le solicita y almacena un token de acceso con credenciales de contraseña del propietario del recurso 3) en el dispositivo iOS para uso futuro.

De vez en cuando, los usuarios se deshabilitan. Me gustaría revocar el token al mismo tiempo. ¿Cómo hago esto? I sospecho que necesito usar el método ICryptoKeyStore.RemoveKey para eso, pero no estoy seguro de cómo encontrar qué tecla eliminar.

Nota 1: en el futuro, el servidor será utilizado por aplicaciones web de terceros.

Nota 2: el requisito de tener credenciales de Tipo de licencia de propietario de recurso proviene del hecho de que se decidió que no vale la pena implementar la redirección del navegador en el dispositivo iOS.

Actualización 1 Algunas excavaciones en el código fuente sugieren que DotNetOpenAuth no admite esta capacidad de forzar la expiración símbolo fuera de la caja. Además, en la vida de implementación estándar del token ni siquiera está marcado. Por lo que puedo ver, el calss es responsable de esto es StandardAccessTokenAnalyzer e ignora las propiedades Lifetime y UtcCreationDate. Tampoco parece que la clase estándar ResourceServer tenga ningún acceso a la base de datos codificado, la validez del token se verifica solo con el contenido del token, por lo que parece que si necesito agregar la capacidad para caducar los tokens necesito cablear el ResourseServer a la base de datos yo mismo . ¿Me estoy perdiendo de algo?

Actualización 2 Creo que he encontrado la respuesta aquí: https://groups.google.com/forum/#!topic/dotnetopenid/aLabu1ujkt4 No es lo que estaba esperando y todavía tengo un par de falta de claridad. Por ejemplo, Andrew escribió:

la clase personalizada, podría realizar un token de acceso, a continuación, utilizar una solicitud HTTP privada al servidor de autorización para verificar la continua validez del token.

No está claro cómo esta verificación puede suceder, ya que no incluye AccessToken ID de autorización. Esto puede dificultar la búsqueda del registro de Autorización de destino. En teoría, podemos tratar de buscarlo combinando el cliente, el usuario y el tiempo de emisión, pero, por lo que puedo ver, no hay garantía de que sean únicos.

Answer 1

De vez en cuando, los usuarios se deshabilitan. Me gustaría revocar el token al mismo tiempo. ¿Cómo hago esto? Sospecho que necesito usar el método ICryptoKeyStore.RemoveKey para eso, pero no estoy seguro de cómo encontrar qué tecla eliminar.

Revoca los tokens al revocar la autorización detrás del token. Esto normalmente significa que elimina una entrada en la tabla de autorizaciones de su base de datos. El efecto que esto debe tener es que su implementación de IAuthorizationServerHost.IsAuthorizationValid devolverá falso para esta autorización.

Esto no revoca inmediatamente los tokens de acceso, pero bloquea el cliente para que no actualice los tokens de acceso caducados.Por lo tanto, siempre que sus tokens de acceso tengan una vida útil razonablemente corta (una hora o menos), la cuenta desactivada de un usuario significa que todo el acceso de los clientes terminará en una hora.

Nota 2: el requisito de tener el tipo de concesión de las credenciales de la contraseña del propietario del recurso proviene del hecho de que se decidió que no vale la pena implementar la redirección del navegador en el dispositivo iOS.

Es su aplicación. Pero les pido a todos que utilicen el flujo de redirección correcto del navegador. Es probable que el usuario ya haya iniciado sesión en su servidor en el navegador del dispositivo, por lo que posiblemente pueda evitar ingresar sus credenciales de esta manera, mejorando sus tasas de conversión. Los usuarios también son más propensos a confiar en el navegador que solicita sus credenciales que una aplicación de dispositivo. Por lo menos eso espero.

Por cierto, es probable que el tipo de concesión de contraseña del propietario del recurso sea no compatible con clientes no autenticados (TBD), que normalmente serán las aplicaciones del dispositivo instalado. Por lo tanto, puede verse obligado a usar un tipo de subvención diferente.

Actualización 1 Algunas excavaciones en el código fuente sugieren que DotNetOpenAuth no admite esta capacidad de forzar la expiración símbolo fuera de la caja. Además, en la implementación estándar, la vida útil del token ni siquiera se verifica. Por lo que puedo ver, el calss es responsable de esto es StandardAccessTokenAnalyzer e ignora las propiedades Lifetime y UtcCreationDate.

DotNetOpenAuth hace cheque por y rechazar tokens de acceso caducados. Simplemente no está en esa clase. Está marcado en el código que deserializa los tokens de acceso.

Además, no parece que la clase ResourceServer estándar ha codificado cualquier acceso de base de datos, la validez símbolo controladas por el contenido simbólico solamente, por lo que parece que si tengo que añadir la capacidad de expirar las fichas que necesito alambre subir el servidor de recursos a la base de datos yo mismo. ¿Me estoy perdiendo de algo?

Tiene razón en que la clase ResourceServer no requiere ningún acceso a la base de datos, ya que se supone tokens de acceso válido para toda su vida (que son no revocable por defecto). Esta es la razón por la cual se recomiendan vidas de token de acceso corto. Esto no es tan lejos como podrías pensar. Por ejemplo, la autenticación de formularios ASP.NET, que muy probablemente ya usa, se basa en el mismo patrón: autentique al usuario una vez, acceda a la base de datos para una verificación de credenciales y luego emita una cookie HTTP cifrada y firmada al agente de usuario. A partir de ese punto, la base de datos no se ve afectada en cada solicitud HTTP entrante: la firma de la cookie se valida y luego se asume que es válida hasta que caduque la cookie. Mismo principio. Excepto que en el caso de la cookie HTTP, hay un tiempo de espera, de modo que mientras el usuario permanezca activo en el sitio, nunca tendrán que volver a autenticarse. Con los tokens de acceso OAuth 2, caducan sin importar cuán activamente se utilicen, forzando una actualización de token que luego puede rechazarse para bloquear el acceso.

No está claro cómo puede ocurrir esta verificación, dado que AccessToken no incluye Id. De autorización. Esto puede dificultar la búsqueda del registro de Autorización de destino. En teoría, podemos tratar de buscarlo combinando el cliente, el usuario y el tiempo de emisión, pero, por lo que puedo ver, no hay garantía de que sean únicos.

Es cierto sin ID está incluido, pero la tupla del cliente-usuario-IssueDate-alcance debe ser único, como su tabla de autorización debe tener una restricción única en él ya que el tener duplicados no tendrían sentido. Además, si no fueran únicos, solo la presencia de cualquier registro con esa tupla sugiere que la autorización es válida.

Espero que esto ayude.