TLDR: If you’re using the Authorization Code flow in a mobile app, Single page application, desktop app, or any other type of application that can’t store a client secret securely (i.e. the only place secure enough is your servers), then you should use the PKCE extension, which provides protections against other attacks where the authorization code may be intercepted and it does not require a client secret.
Sources:
- https://www.ory.sh/oauth2-for-mobile-app-spa-browser/
- https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
- https://www.oauth.com/oauth2-servers/pkce/
- https://security.stackexchange.com/questions/175465/what-is-pkce-actually-protecting
- https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce
TLDR: If you’re using the Authorization Code flow in a web app, that can store a client secret securely i.e on your servers, not someone else devices (computers, mobile phones) then you don't need PKCE, because the code used to exchange against an access token will only reach your servers over a secure connection:TLS, that is absolutely mandatory.
Sources:
The refresh token can be used as soon as the access token has expiried and the user wants to continue using the web app in order to avoid to the user to be prompted again for their login/password (or the OAuth dance in background). The refresh token is used by the server serving the web app used to get a new access token from the Authorization server. The access token is a short-lived token whereas the refresh token has a longer lifespan than its access token.
Weakness:
- The time between the moment the access token is expired and the refresh token is valid is a sensible security window where an attacker who has obtained an expired access token, can get a new access token thanks to the work done by the server to retrieve a new access token from the refresh token still valid. That is the reason why it is important to mitigate the risks using a HTTPS connection (to prevent robbery) but also it is advised to check IP history of the user looking for irregularities before issuing a brand new access token thanks to the refresh token.
- A refresh token can be revoked contrary to an access token, but while a refresh token is revoked, the access token can still be valid (until its expiration date). Thus a there is a time window where an attacker with a still valid access token could abuse the resources servers, that's the reason why it is important to have short-lived access token to mitigate the risk.
Strength:
Maybe you're asking yourself why having an access token and refresh token, if I can renew my access token even when expired with the refresh token, won't it be simpler to just have one token and be done with it. So why ?
-
Security Refresh tokens... mitigates the risk of a long-lived access_token leaking (query param in a log file on an insecure resource server, beta or poorly coded resource server app, JS SDK client on a non https site that puts the access_token in a cookie, etc) Remember refresh tokens are kept within the servers, not anywhere else compared to the access token.
-
Performance Nowaday access token are JSON Web Token that can verified by the resource server without asking the Authorization server. Thus the Authorization server is only called in order to refresh an expired access token, and can check at this occasion if the refresh token has been revoked. Imagine now that we only have a token that can be revoked, the resource server will have to contact the Authorization server everytime to check the token has not been revoked. Here the couple access token/ refresh token make the Authorization server more scalable and the resource server does not rely on the availability of the Authorization server.
Sources: