refresh and access tokens should not have the same lifespan
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- python
- Área
- authentication, security
Línea de trabajo
Empieza rastreando el manejo de la expiración basado en grant_type y los campos de respuesta del token descritos en el issue. Determina cómo las duraciones separadas de access-token y refresh-token pueden conservar la configuración entera existente; después, identifica las pruebas relevantes y verifica ambas formas de configuración y sus expiraciones resultantes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Is your feature request related to a problem? Please describe.
It is common oauth2 practice that when both access and refresh tokens are issued, the refresh token has a longer expiration than the access token. In fact, google mentions this as the recommendation: https://cloud.google.com/apigee/docs/api-platform/antipatterns/oauth-long-expiration#:~:text=A%20good%20starting%20point%20for,lifetime%20of%20the%20access%20tokens.
Set the expiration time for refresh tokens in such a way that it is valid for a multiple of the lifetime of the access tokens
When authlib issues both tokens, it gives them both the same expiration time, since it ONLY keys off the grant_type and does not take token type into consideration. You can see it in the response which has fields for access_token, refresh_token, and a single expires_in.
Describe the solution you'd like
expiration settings should allow for different token lifetimes to be specified for different types.
Backward compatibility could be maintained (e.g. if the expiration setting is an integer for old behavior, or a dict for token type specific expiration settings)
- Lenguaje dominante
- Python
- Estrellas
- 5.4k
- Forks
- 570
- Merge medio
- 1 d 16 h
- PR fusionados (30 d)
- 3
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de authlib/authlib
-
role:client spec:oidc-core
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
-
JSONDecodeError raised instead of a HTTP errorPosiblemente ocupada @juneja-varun la tomó hace 43 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
CVE-2026-96760: fixed or not?Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 57/100
-
[RFC 6749 Conformance] AuthorizationCodeGrant does not enforce code expiration at framework levelAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 38/100
Todos los issues de authlib/authlib
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
pyjanitor-devs/pyjanitor#1758 ·
Los mantenedores suelen responder en 1 día
-
bug ready for review
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
odysseus-dev/odysseus#6641 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
happypawspillaro/happypaws#78 ·
Los mantenedores suelen responder en 4 días
-
pydanty:is-working
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
pydantic/pydantic-ai#10020 ·
Los mantenedores suelen responder en 1 día
-
stdlib type-bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
python/cpython#159044 · 4 comentarios ·
Los mantenedores suelen responder en 1 día