Who DAT ? – Sender-Constraining Personal Acces Token

Access tokens get inadvertently disclosed by users online and such leaks are a common problem that security teams deal with. Coupled with the fact that a leaked access token lets a malicious user use them without any constraints adds to the problem. If the leaked access token has high-privileges that compounds the impact of such a leak. There haven’t been many mitigations that an application or a user generating an access token could use to reduce or eliminate the impact of a token misuse until RFC 9449 came about which introduced a concept called Demonstrating Proof of Possession (DPoP) for OAuth access tokens. Proof-of-possession is a security mechanism at the application level that sender-constrains access tokens by using public/private key pairs. It binds the generated access token to a user's public key and thereby requires attackers to prove possession of the corresponding private key when using that access token. This constrains the access token to the user who generated it, as only they have access to their private key and gives the application, that is receiving the access token, added assurance that it is indeed the user who generated the access token that is using it and no one else. At GitLab, we are working on implementing the DPoP mechanism for Personal Access Tokens to eliminate the impact of accidental token disclosures. In this talk, we will establish why accidental token disclosures are a problem, discuss the DPoP mechanism that we are implementing for personal access tokens, share the technical blueprint we wrote and also demonstrate the PoC showing the solution in action. Participants will leave this talk with a greater understanding of the utility of a mechanism like DPoP and how it can eliminate the problem of access token misuse.