You are correct that client authentication is not required for public
clients (which doesn't preclude the use of refresh_tokens) but from my
perspective it weakens the security because anyone with the
refresh_token is able to get new access_tokens without any additional proof.
Now if the SPA performs some sort of Dynamic Client Registration or DPoP
then I think it's a completely different scenario and it doesn't bother
me as much for their to be refresh_tokens in the browser. This of course
is just my perspective:)
On 7/10/19 7:56 PM, Aaron Parecki wrote:
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.
RFC6749 says "If the client type is confidential or??the client was
issued client credentials,??the client MUST authenticate..." which I
take to mean that refresh tokens could be used without a
client_secret, both for native an javascript apps.
This discussion of offline vs online refresh tokens is interesting,
but I worry that we may be narrowing our focus here too much.
There's a use where JavaScript apps may be able to take advantage of
offline access, which is around Service Workers. This allows a website
to install some code from a website which can continue to run in the
background, though sometimes only while triggered from external
events. One useful example of this is a syncing daemon, where a push
notification can be sent from a web server to a Service Worker, which
could cause that code in the browser to need to make a request to an
API, which then may need to be able to get a new access token, which
is effectively offline access.
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
@aaronpk <http://twitter.com/aaronpk>
On Tue, Jul 9, 2019 at 9:16 AM George Fletcher
<gffletch=40aol....@dmarc.ietf.org <mailto:40aol....@dmarc.ietf.org>>
wrote:
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 <mailto:OAuth@ietf.org>
https://www.ietf..org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
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
