Replies: 1 comment
-
So from a API client perspective, you propose that a client holds a refresh token instead of the real credentials, right? What would be the difference in auth power for this refresh token? How do we codify that? I took a look into Flask-Security to see what they support and did not find too much other than what we use. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Current: The API uses the email and password to retrieve an access token that can then be used to make other requests to the API.
Proposed: The API uses a refresh token to retrieve an access token that can then be used to make other requests to the API.
Using the email and password is limiting in some ways. From Oauth 2.0:
"The resource owner password credentials grant MUST NOT be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.Furthermore, adapting the resource owner password credentials grant to two-factor authentication, authentication with cryptographic credentials (cf. WebCrypto [WebCrypto], WebAuthn [WebAuthn]), and authentication processes that require multiple steps can be hard or impossible."
Some examples of what using a refresh token will allow:
Beta Was this translation helpful? Give feedback.
All reactions