# OAuth 2.0 Access Token Demonstrate Proof of Possession

- Link: https://www.agilicus.com/access-token-dpop/
- Published: 2021-01-05T06:00:00+00:00
- Author: Don Bowman

An Access Token is a cryptographicly-signed key, allowing a system to identify and
authorise itself. The most common format is called JSON Web Token ([JWT](https://zero-trust.ca/)).
In the most common means of use, you open a browser, you login as yourself. An Access
Token is generated representing you, this application, this session. That Access
Token is then stored in your browser. Each web page you open uses it to generate
some API calls after the fact. That is the normal case.

The abnormal case, however, is not as good. If that web page stores the token as
a cookie, it may be intercepted. If it stores it in browser local storage, it could
be scraped from the disk. Malicous JavaScript hosted on the same page might use 
cross-site-scripting request forgery to get access to it. How do you protect yourself?

Well, first start by using a set of best practices. Use a strong [Content-Security-Policy](https://www.agilicus.com/why-should-i-use-content-security-policy/).
[Secure](https://www.agilicus.com/secure-the-cookie/) your cookies. Use the [XSS](https://www.agilicus.com/take-time-to-stop-and-sniff-the-mime-type/)
features. Use the [PKCE Code Flow](https://tools.ietf.org/html/rfc7636). Achieving
this in your web application will make it much stronger, reducing the risk.

What if that is not enough? What if your data is more valuable, your app more risky
than the average? Well, a new IETF draft ([OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)](https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/))
seeks to enhance, to lower the risk. The specification defines a mechanism for sender-
constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application
level. This mechanism allows for the detection of replay attacks with access and
refresh tokens.

Now, in a full [Zero-Trust](https://zero-trust.ca/) model, we would use client-certificates(
[mutual TLS](https://www.rfc-editor.org/rfc/rfc8705.html#name-mutual-tls-client-certifica))
to identify the sender. However, in a typical web application this is not possible.
So, they replace it with a private-key/public-key pair. The applicaton which generated
the Access Token in the first place also has its own private key. Each subsequent
use it signs in such a way the server can see who signed it, but that replace is
not possible.

Now, this does not solve all attacks. In particular, a browser does not have a lot
of options for secure storage of local secrets. So this private key could be stolen
in the same way the access token is. But, it does protect against access tokens 
stolen by network sniffing, from caches, logs, etc.