I'll just add a couple more thoughts around refresh_tokens.
1. I agree with David that refresh_tokens are valuable in an "online"
scenario and should be used there.
2. To use a refresh token at the /token endpoint, client authentication
is required. This is where it gets difficult for default SPAs because
they are public clients and the only mechanism to authenticate them is
the client_id which is itself public. For me, this is the real risk of
exposing the refresh_token in the browser.
3. If the AS supports rotation of refresh_tokens and an attacker steals
one and uses it, then the SPA will get an error on it's next attempt
because it's refresh_token will now be invalid. If the refresh_tokens
are bound to the user's authentication session, then the user can logout
to lockout the attacker. However, that is a lot of "ifs" and still
provides the attacker with time to leverage access via the compromised
refresh_token.
In principle, I agree with the recommendation that SPAs shouldn't have
refresh_tokens in the browser. If it's not possible to easily refresh
the access token via a hidden iframe (becoming more difficult with all
the browser/privacy cookie changes. e.g. ITP2.X) then I'd recommend to
use a simple server component such that the backend for the SPA can use
authorization_code flow and protect a client_secret.
Thanks,
George
On 7/8/19 11:17 PM, David Waite wrote:
On Jul 8, 2019, at 7:10 PM, Leo Tohill <leotoh...@gmail.com
<mailto:leotoh...@gmail.com>> wrote:
Re 8. Refresh Tokens
???? "For public clients, the risk of a leaked refresh token is much
?? ??greater than leaked access tokens, since an attacker can potentially
?? ??continue using the stolen refresh token to obtain new access without
?? ??being detectable by the authorization server.?? "
(first, note the typo "stoken".)
Is it always "higher risk"??? I could even argue that leakage of a
refresh token is lower risk. As a bearer document, a leaked access
token allows access to resources until it expires.?? A leaked refresh
token, to be useful,?? requires an exchange with the AS, and the AS
would have the opportunity to check whether the refresh token is
still valid (has not been revoked). (of course revocation might NOT
have happened, but then again, it might have.)
I agree (with caveats, of course).
Access tokens and refresh tokens may or may not be attached (by
policy) to an authentication session lifetime. It is far easier to
picture refresh tokens which are not attached to an authentication
session (sometimes called ???offline??? access) being inappropriate for a
browser-based app, which is nearly always a client that the resource
owner is interacting with.
Variants that may want offline tokens are less easy to imagine -
perhaps browser extensions?
I believe the language currently there is due to AS implementations
predominantly treating refresh tokens as being for offline access, and
access token lifetime being short enough to not outlast an
authentication session.
Furthermore, since the access token is transmitted to other servers,
the risk of exposure is greater, due to possible vulnerabilities in
those called systems (e.g., logs).?? Isn't this the reason that we
have refresh tokens? Don't refresh tokens exist because access tokens
should have short TTL, because they are widely distributed?
Yes. Once you acknowledge the existence of ???online??? refresh tokens,
they become a strong security component:
- Refresh tokens let you shorten the access token lifetime
- A shorter access token lifetime lets you have centralized policy to
invalidate access without needing to resort to token
introspection/revocation
- Token refresh can theoretically be used to represent other policy
changes by both the client (creating tokens targeting a new resource
server or with reduced scopes) and server (changing entitlements and
attributes/claims embedded within a structured token)
- Refresh tokens can be one-time-use, as recommenced by the security
BCP. A exfiltrated refresh token will result in either the attacker or
the user losing access on the next refresh, and a double refresh is a
detectable security event by the AS.
"Additionally, browser-based applications provide many attack vectors
by which a refresh token can be leaked."
The risks of leaking a refresh token from the browser are identical
to the risks of leaking an access token, right??? This sentence could
be changed to "... by which /a token/ can be leaked."
A refresh token is "higher risk" because its TTL is usually greater
than the access token's TTL.?? But if our advice here leads to people
using longer-lived access tokens (because of the problems with
getting a new access token without involving the user), then the
advice will be counter productive.???? The longer life gives more time
for the usefulness of a browser-side theft, and more time for the
usefulness of a server-side theft.
Which scenario is safer?
A) using an access token with a 10 minute TTL, accompanied by a
refresh token with a 1 hour TTL
B) using an access token with a 1 hour TTL, and no refresh token.
Given tokens that track authentication lifetime, it is hard to make a
case that refresh tokens which last for the authentication session are
a greater security risk than opaque access tokens (requiring token
introspection) that will last the same time.
Typically an AS (or OP) would issue a structured access token with a
lifetime expected to expire before the authentication session, with
new tokens issued via requests made in an embedded, iframe (hidden,
prompt=none). There may be benefits here of user cookies (or perhaps
managed-device information) against an authorization endpoint being
used to make decisions that could not be made by a refresh against the
token endpoint.
I???d be interested in hearing how strong of an implementation issue
this might be for deployments - I could see a non-security argument
that the BCP should only have one recommended approach here, and that
there are deployments needing the iframe approach.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
